text:
Deprecate using non-String keys for nested map properties

When a task or transform parameters object declares a @Nested Map<X, Y> property, we resolve each key in the map to a sub-property. To get the name for each key, we currently call X.toString(), and this is problematic. It can lead to property name collisions, and the names we get this way might not be human well readable (e.g. when falling back to Object.toString()).
We should emit a deprecation warning for @Nested Map<X, Y> properties where X != String.

cc: @gradle/execution

There may be some corner cases when the keys of the maps are GStrings in Groovy. Because of type erasure Groovy probably won't convert them to Strings when you add them to the map. Though I am not sure this is a problem in practice.

authors: lptr wolfs


text:
Short-circuit task dependencies

Expected Behavior
Considering I have a build like this:
// Writes "Gradle" to greeting.txt
val prepare = tasks.register<PrepareTask>("prepareGreeting") {
    message = "Gradle"

    outputFile = layout.buildDirectory.file("greeting.txt")
}

// Reads the greeting from greeting.txt and then writes "Hello, $greeting" to output.txt
val output = tasks.register<OutputGreetingTask>("outputGreeting") {
    dependsOn(prepare)

    greetingFile = layout.buildDirectory.file("greeting.txt")

    outputFile = layout.buildDirectory.file("output.txt")
}

It would be really useful if I could somehow tell Gradle that :prepareGreeting does not produce any output that is useful outside of the :outputGreeting task. The idea would then be that, even if I delete greeting.txt, the :prepareGreeting task could be skipped as long as:

the inputs on :prepareGreeting have not changed
:outputGreeting is otherwise up to date

This could also be very powerful in combination with (remote) build caches, as this mechanism would also allow Gradle to skip downloading any results for :prepareGreeting as long as the conditions (which could be verified locally without the cache, see below) hold true.
My specific use case for this is that I have a bunch of tasks (about 10) that process a rather large jar file. Since task outputs are not supposed to overlap, this means that I also have 10 jar files, of which 9 exist purely for caching purposes, and the final one is actually used as an output. The tasks do make sense as individual tasks, so merging them into one is not really an option for me, as this would also mean that the intermediate results are no longer cached.
Since task dependencies could also produce files that are not (only) meant for other tasks, there would probably have to be some way to differentiate between the cases. Perhaps :outputGreeting could have something similar to this (with better naming):
dependsOn(prepare, outputsAreOnlyRelevantForThisTask = true)

That way, gradle could only apply the logic above for task dependencies that have outputsAreOnlyRelevantForThisTask along the dependency chain, and invoking the task explicitly from the command line or through a regular ´dependsOn` would still always provide the output.
Current Behavior (optional)
Currently, Gradle does not skip :prepareGreeting when I delete greeting.txt.
Context
This is a bit of a chicken-egg-problem, but I think in theory it should be solvable, even if it might be somewhat complex – but it's not like caching isn't complex anyways ;)
The solution could be to do kind of "backwards" UP-TO-DATE check.
We start at leaf nodes of the task graph and check all their inputs. If an input is a regular property, we immediately check whether it is up too date using the usual logic. If the input is a file, we attempt to traverse the task dependencies to find the task which produces that file. We repeat this process for the task that provides the file, and then we consider the file input to be up to date if the producing task is up to date.
In the above example:

We start at :outputGreeting, and look at the greetingFile input.
Since greetingFile is a file, we look for the task producing it, and find :prepareGreeting.
We look at :prepareGreeting, and since the only input is a regular property, we can do a normal up-to-date check.
:prepareGreeting is UP-TO-DATE, so we consider the greetingFile property of :outputGreeting to be up to date.
Since all it's inputs are up to date, and the outputs are there, :outputGreeting is also UP-TO-DATE.

This would mean we successfully checked whether the tasks are up to date without having to run them, and we know :outputGreeting will not run so we can skip :prepareGreeting.

Some similar things have already been suggested in the forums here:

https://discuss.gradle.org/t/short-circuit-dependency-chain-if-task-outputs-exist/35101
https://discuss.gradle.org/t/ability-to-short-circuit-dependencies-with-build-cache/27050

Thank you for your interest in Gradle!
This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

This seems related to coarse-grained execution. @gradle/bt-execution do you track that somewhere?

As @ov7a mentioned, we indeed have a plan to address your use case via a feature called "coarse-grained execution." The idea there is to skip executing intermediate tasks (or indeed load their outputs from the local or remote caches) when we can prove that their transitive inputs haven't changed.
We haven't planned this work yet, though, so I can't say when it will be shipped.

source: gharchive/issue

authors: fxshlein lptr ov7a

repo: gradle/gradle

license_type: permissive

license_source: github-api


text:
Add link to adoc source file to generated html

This fixes #10487

@melix I wanted to do it as part of flatten sources but I did not have a good idea how because I need the original file path. If I would do it in doFirst, I would modify the original file (which we don't want). In doLast I have lost the original path already.
Do you have another good and simple idea?

source: gharchive/pull-request


text:
Fix file watching soak test

We now don't invalidate the whole VFS if we
receive an overflow for some location. So
the number of retained files won't be 0.
Moreover, sometimes changing the files takes
more than 2 minutes which may cause the daemon
to time out.
Fixes https://github.com/gradle/gradle-private/issues/3093.

@lptr PTAL, I removed the increased idle timeout.

@lptr PTAL!


text:
Bump deprecation warnings from 7.0 to 8.0

The updated places are:

tests where the warnings act as test data.
Deprecation of 'force' was extended
Deprecation of 'SourceDirectorySetFactory' was extended (#15844)

@bot-gradle test QFL

OK, I've already triggered QuickFeedbackLinux build for you.

@bot-gradle test QFL

OK, I've already triggered QuickFeedbackLinux build for you.

authors: bot-gradle jjohannes


text:
Fix BuildOperationTrace with debug on Java 8

The first log event which ends up in BuildOperationTrace initializes the Groovy VM on the call of JsonOutput.toJson(). That is not bad as is, only on Java 8 this causes the logging of an exception while initializing the VMPlugin. And from the debug logging, we end up in the trace again which tries to call JsonOutput.toJson() again. Since the VMplugin isn't initialized, yet (we are just in the middle of it), we end up with an NPE and the build fails.
So we need to initialize the VMPlugin before we start writing traces.
If the log level is not debug, the Groovy VM doesn't log the error, so we don't come into this situation.
Fixes https://github.com/gradle/gradle-private/issues/3393.

Finally I ended up ignoring the logging from VMPluginFactory in OutputEventListenerBackedLoggerContext, which also resolves the problem.

could you have a test that enables operation trace + debug?

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.

authors: big-guy bot-gradle wolfs


text:
Restore Previous Test Options Behavior (for Release Branch)

Fixes #19058
Context
This is a continuation of this PR, with the work rebased against the release branch.  Please see that PR for many explanatory comments.

Ignore the 74 in the branch naming, it should be 731.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test and merge

OK, I've already triggered a build for you.

authors: bot-gradle tresat


text:
Prevent corrupt build logic jars by running all build logic builds with the same file lock

Gradle has a lock around building buildSrc and putting the result in the JARs cache. So everything will be synchronized between builds and no bad things can end up in the JARs cache. The resulting JARs will end up on the classpath of the build this buildSrc belongs to.
For included builds, we don’t have such a lock. So when you run two builds concurrently, building and putting stuff from build-logic builds in the JARs cache will happen concurrently. That means it is quite probable that something bad ends up in the JARs cache.
This PR addresses the problem by running all build logic builds (buildSrc and included builds) from a particular build tree with the same file lock.
Fixes #20830

@bot-gradle test QFL

I've triggered the following builds for you. Click here to see all build failures.

QuickFeedbackLinux build

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.

authors: bamboo bot-gradle


text:
Allows for configuring RepositoryMode in settings in a declarative manner

This would support some currently commented out usage in the Now In Android prototype.
This is necessary because we don't want to support using enum constants in DCL files directly.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

❌ I don't think we should do this until we resolve what our enum strategy is in DCL files.

Yes, this is on pause for now.


text:
Move ExceptionAnalyzer service interface to problems-api subproject

To finish https://github.com/gradle/gradle/pull/30164, the Problems service needs to see and use ExceptionAnalyzer. To enable that, the service interface is moved to the problems-api package. The implementation is kept in its original location as it has a dependency to internal sibling classes.
Fixes https://github.com/gradle/gradle/pull/31237

@bot-gradle test RFM

I've triggered the following builds:

Pull Request Feedback (Trigger) (Check)

Build Scan

Superseded by https://github.com/gradle/gradle/pull/30164

authors: bot-gradle donat


text:
Convert more transforms to the new API

More dogfooding!

@gradle/kotlin-dsl: Can you have a look at the converted transforms related to Kotlin? That would be the parameter names transform and the distribution sources transform.


text:
Query as table

Hi,
I have a problem with the table visualization when a datetime column is present.
First screenshot, query all values from a clickhouse server, with the clickhouse plugin, table contains a datetime column.

Second screenshot, query all values from the same server same table, but with the mysql plugin, and select "Format as Table" at the bottom

I guess the automatic detection of the timeserie is not taking into account that on the right I have selected the table plugin, and it's creating a json of all columns, when instead it should just return the rows as they are.
Thanks

@syco can't seem to reproduce.  It should only format as time series if you add a time alias.  What version are you on?

I was using Grafana v8.3.4 (a551d74b11) with Clickhouse plugin 0.9.7,
I updated the plugin to 0.9.9 and it's working as expected now.
Thanks

authors: scottlepp syco

repo: grafana/clickhouse-datasource


text:
Snapshot: add plugin, annotation and report data types

Adding the types to the constants in order to support migrating plugins, annotations and reports.
Part of https://github.com/grafana/grafana-operator-experience-squad/issues/1036

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant dana-axinte


text:
After Upgrade to Version 4.4.6 -  "Invalid params. Login name or password is incorrect."

Hello All,
Zabbix Version 3.2.11
Grafana Version 9.3.2
grafana-zabbix Version 4.4.6
After upgrading grafana zabbix from 4.2.9 to 4.4.6 i now get the following message on "save & test"
"Invalid params. Login name or password is incorrect."
I am sure the password is correct.

Logs:
logger=plugin.alexanderzobnin-zabbix-datasource t=2024-03-17T10:44:16.317717163+01:00 level=error msg="Zabbix authentication error" error="Invalid params. Login name or password is incorrect."
logger=plugin.alexanderzobnin-zabbix-datasource t=2024-03-17T10:44:16.318444609+01:00 level=error msg="Zabbix API request error" error="Invalid params. Login name or password is incorrect."
logger=context userId=1 orgId=1 uname=admin t=2024-03-17T10:44:16.318699523+01:00 level=error msg="Request Completed" method=POST path=/api/datasources/2/resources/zabbix-api status=500 remote_addr=x.x.x.x time_ms=12 duration=12.265909ms size=98 referer=http://x.x.x.x:3000/datasources/edit/7xYofH1Sz handler=/api/datasources/:id/resources/*
Can anyone help me out?
Thanks!

UPDATE: I tried various grafana-zabbix plugin versions. This issue shows up from version 4.3.0 onwards.

Hi @frankie7, Your version of zabbix is verry old. There have been several changes since version 3.2 of zabbix. In this scenario, I would recommend updating the zabbix version to a supported LTS version (6.0 for example) or continuing to use version 4.2.9 of the plugin, in the same way, several queries may not work correctly.

Hi @frankie7, Your version of zabbix is verry old. There have been several changes since version 3.2 of zabbix. In this scenario, I would recommend updating the zabbix version to a supported LTS version (6.0 for example) or continuing to use version 4.2.9 of the plugin, in the same way, several queries may not work correctly.

Hi Bernardo, you are very right indeed. The problem is we inherited this old Zabbix version which is very hard to upgrade (lots of database issues). So at the moment i'm looking for a "quick and dirty" fix.

It would be nice to fix this issue so to use more recent versions of the grafana-zabbix plugin and make the "Angular JS" warning disappear (>= 4.3.0)

Hi @frankie7, Your version of zabbix is verry old. There have been several changes since version 3.2 of zabbix. In this scenario, I would recommend updating the zabbix version to a supported LTS version (6.0 for example) or continuing to use version 4.2.9 of the plugin, in the same way, several queries may not work correctly.

Hi @bernardolankheet, you are very right indeed. The problem is we inherited this old Zabbix version which is very hard to upgrade (lots of database issues). So at the moment i'm looking for a "quick and dirty" fix.

Plugin development and support are only for versions still maintained by Zabbix. Supporting versions older than 8 years would be very costly. And I believe that keeping such an old version of zabbix is fine too.
In this scenario, it is recommended to update Zabbix.

Hi @frankie7, Your version of zabbix is verry old. There have been several changes since version 3.2 of zabbix. In this scenario, I would recommend updating the zabbix version to a supported LTS version (6.0 for example) or continuing to use version 4.2.9 of the plugin, in the same way, several queries may not work correctly.

Hi @bernardolankheet, you are very right indeed. The problem is we inherited this old Zabbix version which is very hard to upgrade (lots of database issues). So at the moment i'm looking for a "quick and dirty" fix.

Plugin development and support are only for versions still maintained by Zabbix. Supporting versions older than 8 years would be very costly. And I believe that keeping such an old version of zabbix is fine too.
In this scenario, it is recommended to update Zabbix.

Thanks for your  suggestion, o hope i'll manage to upgrade the Zabbix platform soon :)

repo: grafana/grafana-zabbix


text:
Specify k6 container when reading logs

Signed-off-by: Marcos Candeia marrcooos@gmail.com
See #164

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant mcandeia


text:
Combine all initializer commands with && to catch any failing commands

By running two commands instead of one (the second being the cat | grep), any failures (non-zero exit code) of the first part (containing k6 inspect) will be lost and masked away.
By chaining them all with && the first non-zero RC will fail the whole command and return.
Fixes: #435

@frittentheke, thank you for the PR! It seems like you have opened 2 PRs? Could you please leave only one?
Quickly skimming the code, the change seems reasonable on the first glance, but I need to look up the details there again. Additionally, this change requires testing. I'll be able to fully review this in a couple of weeks approx. Hope that's alright!

@frittentheke, thank you for the PR! It seems like you have opened 2 PRs for the same issue? Could you please leave only one?

I changed one to draft and shall remove the "fixes" reference to this issue. It is simply not "just" a bugfix.
Thanks for looking into and testing #435.

Hi @frittentheke, would you be able to modify the PR to leave only the first change, in common.go? We're going to have a release this week, and it'd be preferable to merge that fix before that.
We can continue discussion about the second change at a later point / in another PR, of course.

@frittentheke, sorry for the delay! I've finally managed to test this PR a bit. So there are 2 parts:
1. correct error return in `common.go`: that's a great catch; thank you!

2. the `k6 inspect` command: I'm afraid this change makes debugging more complicated than before. The current flow, with `;`, allows one to see error in logs of initializer. Example user flow: user sees an `initializer job has failed` in k6-operator's logs and then can go and see the exact error in initializer logs. But with `&&`, initializer fails and leaves no logs afterwards. AFAIS, it becomes harder to debug the problem. If you could describe a more specific case of initializer failure that you were looking into, please do! Otherwise, I'd request to omit this part as I don't see how it helps ATM...

@yorugac  sorry for the delay ...
Regarding 1) I created a new PR with just the var typo fixed: https://github.com/grafana/k6-operator/pull/465
As for 2) :
I'd like to argue that the current flow actually only handles certain types of errors - those that go into that very output file /tmp/k6logs and that are then caught by the grep filter level=error- but then misses others: Any issues with the initializer (causing non-zero exit codes) or cause none of those error lines to be emitted are then lost and the initializer actually falsely succeeds as the original return code of the inspect is masked or lost and only the one from the grep command counts for the pod termination. In my case, which made me write up the PR, the inspect command was not able to start (due to some imports being wrong) and the initializer still succeeded as there was not output with level=error and the k6-operator got stuck in the next phase (no JSON output, no jobs, ...).
To me any unexpected non-zero return code should be handled as an error (I know about https://github.com/grafana/k6/issues/2804, https://github.com/grafana/k6-operator/issues/75, ...). A while back I started a bigger PR (https://github.com/grafana/k6-operator/pull/450) completely reworking the way the initializer works through the various tasks and then sends off it's verdict via termination log, the kubernetes-native way of handling this phase (https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/). But that PR / discussion is for another day I suppose. If you even like the idea to rework the whole thing to make it a lot more robust.

@yorugac with 0.17.0 released would you consider discussing 2) some more? If you agree that my chain of thought is not totally off and would consider a rework the likes of https://github.com/grafana/k6-operator/pull/450 I'd gladly take in some feedback there to finish the PR.

Hi @frittentheke, apologies for this delay! I've got swamped with internal work. And thank you for your patience! :joy:
You described this case:

In my case, which made me write up the PR, the inspect command was not able to start (due to some imports being wrong) and the initializer still succeeded as there was not output with level=error and the k6-operator got stuck in the next phase (no JSON output, no jobs, ...).

AFAIR, when imports are off, there should be logs left in initializer which then should cause an error in k6-operator on JSON unmarshal. It sounds like it wasn't so for you, so no logs despite the import error? If so, could you please share a script how to repeat that situation?

Sorry @yorugac for again getting back to you late on this one ... But I just remembered when we ran into yet another issue of  this kind ;-)

AFAIR, when imports are off, there should be logs left in initializer which then should cause an error in k6-operator on JSON unmarshal.

Yes, that is indeed the case:
2024-12-10T12:02:19Z    ERROR    controllers.TestRun    unable to marshal: ``
{"namespace": "loadtesting", "name": "sometestname", "reconcileID": "d6353a2a-8b15-4319-85fa-96a63c7be8eb", "error": "unexpected end of JSON input"}
github.com/grafana/k6-operator/controllers.inspectTestRun/workspace/controllers/common.go:112
github.com/grafana/k6-operator/controllers.RunValidations/workspace/controllers/k6_initialize.go:55
github.com/grafana/k6-operator/controllers.(*TestRunReconciler).reconcile/workspace/controllers/testrun_controller.go:13
github.com/grafana/k6-operator/controllers.(*TestRunReconciler).Reconcile/workspace/controllers/testrun_controller.go:80
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Reconcile/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.19.0/pkg/internal/controller/controller.go:116
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.19.0/pkg/internal/controller/controller.go:303
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.19.0/pkg/internal/controller/controller.go:263
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func2.2/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.19.0/pkg/internal/controller/controller.go:224

but this requires someone to look at the logs and does not contain any real clues to what the issue (of the initializer run) is.
At the very least I'd like to have the initializer job fail (with non-zero return code), thus this very PR combining all commands to have any non-zero return codes make the job fail (read: "initialization failed").
I'd then really love to discuss a redesign the likes of https://github.com/grafana/k6-operator/pull/450 to give the user back the log output (STDOUT + STDERR) for the initializer.

authors: frittentheke yorugac


text:
Make PostingsForMatchersCache.PostingsForMatchers respect context cancellation

Make PostingsForMatchersCache.PostingsForMatchers respect context cancellation when executing queries (to populate cache), by executing them in a background goroutine taking a dedicated context, which gets canceled once no PostingsForMatchers caller needs it any more.
Fixes https://github.com/grafana/mimir-prometheus/issues/548.
TODO:

[ ] Add test exercising concurrent access, where most accesses should use the cache

I'm wondering if we can just accept that occasionally we'll waste some cycles completing a postings for matchers call for a caller that has already cancelled.

@charleskorn as discussed offline, I see your concern, and I think we'll need to analyze the necessity of being able to cancel executing queries in the light of past issues at Grafana Labs.

Superseded by #644

repo: grafana/mimir-prometheus


text:
POC: support paging with streaming queries

We currently support paging by having the client submit additional requests over HTTP when a nextToken exists -- this PR explores how we could service the requests with a continuous stream from the backend.  This uses the new live features in grafana 8
TODO?

should this be optional, or the standard way to support multiple pages?
this using the standard StreamingDataFrame processing -- do we need anything different?

:thinking: hymm -- thinking more about this... I don't think this solves our HA issue, since the initial query may be on a different node than when the client returns to get the streaming updates

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I'm going to close this since it's pretty old, but it'll be there if we want to revisit.

authors: CLAassistant njvrzm ryantxu

repo: grafana/timestream-datasource


text:
Plugin support for Grails 3.3.0.M2

My current environment:

grailsVersion=3.3.0.M2
gormVersion=6.1.4.RELEASE
gradleWrapperVersion=3.5
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)

When I try to start my applicatin using 'run-app', I get the following:
2017-06-11 15:20:09.969 ERROR --- [           main] o.s.boot.SpringApplication               : Application startup failed
groovy.lang.MissingPropertyException: No such property: DATE_FORMATS for class: org.grails.plugins.databinding.DataBindingGrailsPlugin
at groovy.lang.MetaClassImpl.invokeStaticMissingProperty(MetaClassImpl.java:1002)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1857)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1833)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3758)
at org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:51)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:296)
at org.grails.plugins.web.Java8GrailsPlugin$_doWithSpring_closure1.doCall(Java8GrailsPlugin.groovy:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1426)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
at groovy.lang.Closure.call(Closure.java:414)
at groovy.lang.Closure.call(Closure.java:408)
at grails.spring.BeanBuilder.invokeBeanDefiningClosure(BeanBuilder.java:759)
at grails.spring.BeanBuilder.beans(BeanBuilder.java:588)
at grails.spring.BeanBuilder.invokeMethod(BeanBuilder.java:531)
at org.grails.plugins.DefaultGrailsPlugin.doWithRuntimeConfiguration(DefaultGrailsPlugin.java:559)
at org.grails.plugins.AbstractGrailsPluginManager.doRuntimeConfiguration(AbstractGrailsPluginManager.java:167)
at grails.boot.config.GrailsApplicationPostProcessor.postProcessBeanDefinitionRegistry(GrailsApplicationPostProcessor.groovy:171)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:118)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:686)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:524)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:737)
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:370)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:314)
at grails.boot.GrailsApp.run(GrailsApp.groovy:83)
at grails.boot.GrailsApp.run(GrailsApp.groovy:388)
at grails.boot.GrailsApp.run(GrailsApp.groovy:375)
at grails.boot.GrailsApp$run.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133)
at maverick.Application.main(Application.groovy:8)
2017-06-11 15:20:09.986 ERROR --- [           main] o.s.b.f.s.DefaultListableBeanFactory     : Destroy method on bean with name 'grailsApplicationPostProcessor' threw an exception
java.lang.IllegalStateException: ApplicationEventMulticaster not initialized - call 'refresh' before multicasting events via the context: org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@3676ac27: startup date [Sun Jun 11 15:20:04 CAT 2017]; root of context hierarchy
at org.springframework.context.support.AbstractApplicationContext.getApplicationEventMulticaster(AbstractApplicationContext.java:404)
at org.springframework.context.support.ApplicationListenerDetector.postProcessBeforeDestruction(ApplicationListenerDetector.java:97)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:253)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:578)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:554)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:961)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:523)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:968)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1033)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1009)
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:961)
at org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:794)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
at grails.boot.GrailsApp.run(GrailsApp.groovy:83)
at grails.boot.GrailsApp.run(GrailsApp.groovy:388)
at grails.boot.GrailsApp.run(GrailsApp.groovy:375)
at grails.boot.GrailsApp$run.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133)
at maverick.Application.main(Application.groovy:8)
2017-06-11 15:20:09.988 ERROR --- [           main] o.s.b.f.s.DefaultListableBeanFactory     : Destroy method on bean with name 'org.springframework.boot.autoconfigure.internalCachingMetadataReaderFactory' threw an exception
java.lang.IllegalStateException: ApplicationEventMulticaster not initialized - call 'refresh' before multicasting events via the context: org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@3676ac27: startup date [Sun Jun 11 15:20:04 CAT 2017]; root of context hierarchy
at org.springframework.context.support.AbstractApplicationContext.getApplicationEventMulticaster(AbstractApplicationContext.java:404)
at org.springframework.context.support.ApplicationListenerDetector.postProcessBeforeDestruction(ApplicationListenerDetector.java:97)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:253)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:578)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:554)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:961)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:523)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:968)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1033)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1009)
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:961)
at org.springframework.boot.SpringApplication.handleRunFailure(SpringApplication.java:794)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:325)
at grails.boot.GrailsApp.run(GrailsApp.groovy:83)
at grails.boot.GrailsApp.run(GrailsApp.groovy:388)
at grails.boot.GrailsApp.run(GrailsApp.groovy:375)
at grails.boot.GrailsApp$run.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133)
at maverick.Application.main(Application.groovy:8)
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':maverick:bootRun'.

Process 'command 'C:\Program Files\Java\jdk1.8.0_73\bin\java.exe'' finished with non-zero exit value 1

@jameskleeh will there by a Grails 3.3 compatible version before Grails 3.3 gets officially released?

resolved this error in Grails 3.3.0 by adding this dependency
compile "org.hibernate:hibernate-java8:$hibernateVersion"

Fixed with version 1.2.1

authors: jameskleeh mftruso pjdvmalan saw303

license_source: bigquery


text:
Add unused but explanatory async

In response to https://github.com/grammyjs/grammY/issues/431
@dcdunkan are there any more such places? We have dozens or even hundreds of code examples with async handlers, but the rule is that anything that can be misunderstood will be misunderstood sooner or later. It's probably best to always add async, except for lambdas without block such as (ctx) => ctx.reply("42").

Ready to merge then :)

I will take that as it is not translatable.

repo: grammyjs/website

license: MIT


text:
Sharded matrix multiplication and tests refactor

Sharded matrix multiplications stored in the sharded submodule. Only three were implemented to support common cases for tensor and data parallel training applications.
Tests for collectives were refactored to reuse utilities.

I'm afraid I have discovered serious review fatigue & simply cannot get my mind in gear w.r.t. the details of sharding, so I've reviewed all but the tests. @AlCatt91 can I rely on your review there?

Yes of course, happy to take a closer look at the tests.

LGTM


text:
Feature Request: center-on-location search box

I'd find it convenient to be able to center the map view to a specific latitude/longitude, as in the simple search box seen on common mapping services.  In particular, when working with a route that has dozens of points covering hundreds of kilometers, it's difficult to home in on a specific place (e.g. a customer location) to see how the map routes nearby.

@jeffrey-friedl Is there something more required in the new GH Maps? You can right click the map to get the coordinates.

This was not a request to display the coordinates of a location, but to have a way to get a specific location to appear on the screen without making any changes to the route... a "zoom in on XXXX" feature.   This was all discussed in this thread last year.  I ended up implementing it in a local version (along with an "extend track to..." feature, and a bunch of other changes that make it a much-more useful tool for me), so I no longer use the one at GraphHopper.com

Can you describe how it looks? Is it a new entry in the context menu that basically replaces clicking on "Add Location" and then right click on the map and "To here"?

Yes, exactly.

repo: graphhopper/graphhopper-maps


text:
Interpolates elevation for tunnels and bridges, fixes issue #713

This is the fix for #713. It adds elevation interpolation for tunnels and bridges.
For this to work you'll need to turn on the generic flag encoder:
graph.flag_encoders=generic,car,foot

This will probably also require using 8 bytes for flags:
graph.bytes_for_flags=8

Elevation can be turned off via:
graph.elevation.interpolate.bridges=false
graph.elevation.interpolate.tunnels=false

(Both settings are true by default.)
See this tweet for example.
How it works.
For each tunnel (or bridge) edge, the algorithm first finds a connected component of tunnel (bridge) edges. Thus we can find "inner" and "outer" nodes of the tunnel. Outer nodes have tunnel and non-tunnel edges whereas inner nodes only have tunnel edges. Outer nodes are considered to be on the Earth surface, therefore we can trust the elevation provider for their elevation.
Once we've found inner and outer nodes, we'll interpolate elevations of inner nodes based on the elevations of the outer nodes. Interpolation method depends on the number of outer nodes. Cases for 0 or 1 outer nodes are trivial. For 2 outer nodes we use linear interpolation. For 3 outer nodes we use planar interpolation. For 4 and more outer nodes we use the following method.
This is how we get elevations of the inner nodes. Elevation of pillar points is then calculated using linear interpolation using distances from the pilar node to the tower nodes.
Few further hints.

I had to add some default implementation to DataFlagEncoder.flagsDefault, as it was called during initialization.
I had to add motorroad and forrestry to the highwayList in DataFlagEncoder, otherwise GraphHopper was failing with Graph not prepared for highway=forestry error during initialization.
DataFlagEncoder seems to require 26 bits which I think is a bit too much. It does not feel completely finished yet, but is sufficient for this issue.

I'd be grateful for the review and merge.

Few further hints.

Thanks! The DataFlagEncoder is a bit unpolished at the moment.

DataFlagEncoder seems to require 26 bits which I think is a bit too much

This is correct and will continue to grow probably to 64bit. E.g. we store the maximum speed for cars currently forward&backward leading already to 2*5bits - we could probably do a bit better if we do not store multiples of 5 but use e.g. 0,1,2,3,4, ... for common speeds like 5, 10, 20, 30, 50?
Also the intention is to fully move everything to this encoder (as often "raw data" is necessary) and potentially breaking the long-flags into two ints and adding a third int, then providing edge.getData(int). This way we are no longer limited by 64bits. But for the most use cases 64 will be sufficient, at least this is the plan :)

Elevation can be turned off via:

You mean interpolation here? I would not make this configurable. I would enable interpolation as soon as elevation is enabled and the DataFlagEncoder is there.

I understood the intention of the DataFlagEncoder but I also think we'll need more that 64 bits in the long run. Optimizing speed bits would give 2-4 bits most (I don't think we can go below 8 different speeds, that's at least 3 bits per direction, but 4 bits is more realistic).

Elevation can be turned off via:
You mean interpolation here? I would not make this configurable. I would enable interpolation as soon as elevation is enabled and the DataFlagEncoder is there.

Yes, interpolation. I've added these configuration options for a backward compatibility path. I'm OK to drop it. Should I do it or could you do it upon merge?

(I don't think we can go below 8 different speeds, that's at least 3 bits per direction, but 4 bits is more realistic).

What is even worse: we need two speed values for hgv and potentially others too. Highly likely a dynamic storage size per edge should be introduced but then we cannot easily use it like an array and would need a binary search for every index. Not sure yet how to solve this efficiently.

I've added these configuration options for a backward compatibility path.

Currently no one uses DataFlagEncoder so we should be save :)

I'm OK to drop it. Should I do it or could you do it upon merge?

I can do this

Thank you for the review! I'll make the changes and commit shortly.

Done.

Thanks again!
Merged via https://github.com/graphhopper/graphhopper/commit/90a3844cd3f9768cef97d4db491d064cc1e08bfc

authors: highsource karussell

repo: graphhopper/graphhopper


text:
Fix subscription semaphore

This currently isn't doing anything because we were not awaiting for the semaphore.

I'm working on using a single semaphore for subscriptions and queries so this won't matter.

repo: graphprotocol/graph-node


text:
Sub-objects are null when returned to Graphiql

I have an app that uses graphql-maven-plugin to provide a front-end for a REST service.
When I gather the data and return the object generated by the plugin in the DataFetchersDelegateImpl class for the query, all relevant data is present. So the conversion using Dozer is working well.
However, when returned to the GraphiQL front-end, the two fields that are objects are null.
Am I missing something in the logic of how this works, or is there a step I'm not performing?

What is the GraphQL query, that you execute ?
I guess that in graphiql, your request didn't ask for all the fields you want to see.
Étienne

The query I execute is
{
  getReservation {
    xmlns
    xmlnsxsi
    xsischemaLocation
    Version
    Target
    PrimaryLangID
    TimeStamp
    VehRetResRsInfo {
      TPA_Extensions {
        VendorPictureURL
        IsFreesale
        Status
        CancellationPolicy
      }
    }
    VehRetResRsCore {
      VehReservation {
        Status
      }
    }
  }
}

and the (redacted) response is:
{
  "data": {
    "getReservation": {
      "xmlns": "appropriate String1",
      "xmlnsxsi": "appropriate String2",
      "xsischemaLocation": "appropriate String3",
      "Version": "1.002",
      "Target": "Test",
      "PrimaryLangID": "EN",
      "TimeStamp": "2021-11-25T09:46:50.324Z",
      "VehRetResRsInfo": null,
      "VehRetResRsCore": null
    }
  }
}

The object returned from the DataFetchersDeleteQueryImpl class contains a value of "Confirmed" in the Status field of VehReservation in VehRetResRsCore

From your request, VehRetResRsInfo and VehRetResRsCore are objects.
So you should have VehRetResRsInfoDelegate and VehRetResRsCoreDelegate  interfaces. The value returned by the query is the value returned by these data fetcher implementations.
The value for these fields returned in the DataFetchersDeleteQueryImpl is ignored by default.
You can probably check in the VehRetResRsInfoDelegate and VehRetResRsCoreDelegate  implementations if the source object contain this fields. In which case you can return them.
This is the way GraphQL works : it fetches one level, then recurse the next level. This prevents to fech useless data : your server implementation is done without knowing if your client request will query the VehRetResRsInfo and VehRetResRsCore or not.
So GraphQL take only into accounr the return of the  data fetcher implementations of these two fields. And more important: it will call them only if it's usefull, from the requests that has been received.
Etienne

Ah, I see - that is a fundamental misunderstanding on my part.
Thank you for your explanation. I'll close this conversation as it's not an issue any longer.

authors: TrueDub etienne-sf


text:
Handling MultiPart Form Requests

GraphQL controller that  handles multi part requests. When request contains multipart data its being deserialized and then files are put into request via request.getFiles.put(...). The one requirement to make it work is putting files as variable to GraphQL request, like it is suggested everywhere when sending files via GraphQL is mentioned.
Integraton test included.
Example on integrating graphQL with file transfer:
import graphql.schema.*;
import org.springframework.web.multipart.MultipartFile;

import javax.servlet.http.Part;

public class Scalars {
    public static final GraphQLScalarType UpFile =
            GraphQLScalarType.newScalar().name("UpFile")
                    .description("A file part in a multipart request").coercing(new Coercing<MultipartFile, Void>() {
                @Override
                public Void serialize(Object dataFetcherResult) throws CoercingSerializeException {
                    throw new CoercingSerializeException("Upload is an input-only type");
                }

                @Override
                public MultipartFile parseValue(Object input) throws CoercingParseValueException {
                    if (input instanceof MultipartFile) {
                        return (MultipartFile) input;
                    } else if (null == input) {
                        return null;
                    } else {
                        throw new CoercingParseValueException("Expected type " +
                                Part.class.getName() +
                                " but was " +
                                input.getClass().getName());
                    }
                }

                @Override
                public MultipartFile parseLiteral(Object input) throws CoercingParseLiteralException {
                    throw new CoercingParseLiteralException("Must use variables to specify Upload values");
                }
            }).build();
}

Would be nice to see this feature in the project.

authors: AnkBurov jakubbrodzinski

repo: graphql-java/graphql-java-spring


text:
Add clarifications about edge order to the relay cursor connections specification

I'm not sure where the repo for the specification webpage lives.  Hopefully this is the right place for this issue?
Recently while working on improving graphql-sequelize's implementation of connections, I discovered that, as far as I understand, someone misinterpreted the specification: their implementation returns edges in the opposite order when the last argument is used.  This also means the startCursor and endCursor are swapped, and their reverse pagination test fetches the previous page by requesting last: 3, before: pageInfo.endCursor.  But as far as I understand before should always take the startCursor of the current pageInfo.
I've submitted a PR to fix their implementation but I'd also like to help prevent this kind of misinterpretation for anyone in the future.
Adding the following clarifications to the Relay Cursor Connections Specification would precisely specify the ordering of edges:

The ordering of edges should be the same when using first/after as when using last/before, all other arguments being equal
To fetch the next page one should use after: pageInfo.endCursor, not after: pageInfo.startCursor
To fetch the previous page one should use before: pageInfo.startCursor, not before: pageInfo.endCursor
When before: cursor is used, the edge closest to cursor should come last in the result edges.
When after: cursor is used, the edge closest to cursor should come first in the result edges.

Okay this needs to go in facebook/relay, I'll move it there.

For people coming from Google, the issue moved here https://github.com/facebook/relay/issues/2466

@yvele ah thanks, sorry I forgot to do that!

repo: graphql/graphql-relay-js

license: mit


text:
Run validate-links after remarkVariables

Linting via remark was failing because some link URLs included variables
in the link target, e.g.:
[CM-08]((=fedramp.control_url=)CM-8), where the fedramp.control_url
variable value is a valid URL that includes a query string containing
the value after the variable.
validate-links would be run before remarkVariables, so links like this
would fail the linter since the variables were not being resolved.
This change runs validate-links after remarkVariables to ensure the
linter can check fully evaluated links.

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1202483794575373

Thanks, @jeffgaynor! Since I don't have write access, would you mind merging this?

repo: gravitational/docs


text:
adding tests for member in v2 APIs (GKO-331)

This will add 2 tests for member in v2 APIs (GKO-331):

should change the role of an API member
should change the role of an API member

It's automating the following manual tests
GKO-308
GKO-393

Last little thing, can we add link to the ticket and rename commit message to
test: add tests for member in v2 APIs

IE removing ticket numbers and use present

authors: a-cordier ctschacher


text:
Archi 296 upgrade bom

Issue
https://gravitee.atlassian.net/browse/ARCHI-296
Description
update and fix following bom upgrade
Additional context

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 5.4.0-archi-296-upgrade-bom-SNAPSHOT
download it from Artifactory here

:tada: This PR is included in version 5.4.0 :tada:
The release is available on:

5.4.0
GitHub release

Your semantic-release bot :package::rocket:

authors: benoitgravitee graviteeio

repo: gravitee-io/gravitee-node


text:
[Bug]: Netclient Deamon : WireGuard interfaces keep being enabled/disabled

Contact Details
No response
What happened?
In the current version of netclient it wil constantly try to connect to the Broker. And if this fails it wil restart the entire daemon, and as a consequence it wil also disable and renable the WireGuard interfaces. Which can cause an temporary outage.
Would it be possible to only disable/reenable these interfaces when new changes need to be applied. Meaning:
If the deamon restarts, the WireGuard interfaces already exists and the config is correct, the deamon won't touch the WireGuard interfaces.
I would love to know if this could be implemented, this would help immensely in an environment where mqtt/WS-connections can be weird
Version
v0.16.3
What OS are you using?
Linux
Relevant log output
No response
Contributing guidelines

[X] Yes, I did.

#548 has been reverted.  additional work required

authors: LucaOonk mattkasun

repo: gravitl/netclient


text:
Support for passing args

I'm running a martini server using fresh and I need to pass some command line args to my program, but can't find any support for it.
It would be great with either a command line switch for the fresh command:
fresh -a "--my-custom-arg=123 --and-another=true"

... or an option in the config file:
args: --my-custom-arg=123 --and-another=true

Perhaps both?

+1

@lateefj if you can rebase I can check again and then merge your PR

Any movement on this? This would be a really-nice-to-have™

@jhartman86 I have updated my PR (#10).

@aferrandini You install based on my fork since it doesn't look my PR is going to get merged to master

This would be incredibly useful. What's blocking it?

authors: jhartman86 joaocarmo lateefj owickstrom pilu santacruz123

repo: gravityblast/fresh


text:
Add support for options with identical values.

Context

https://secure.helpscout.net/conversation/2457894739/59140/
https://secure.helpscout.net/conversation/2449770325/58821?folderId=6987275

Summary
Adds support for including options with duplicat options.

@veryspry I am getting the same problem here. For the point 2, I can also add the postal codes feature, in some countries with the same code you can get multiple cities, and without allowing duplicated values, it is impossible to use this library...

authors: sovetski veryspry

repo: gravitywiz/tom-select


text:
feat(tools): add eslint shareable config

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information
The only rule not copied from the root config is the import order, as that is only relevant to this project.

Is there a way to get our rules to pull from this one natively so that there's only one config?

@damienwebdev we can point npm to a file: "@daffodil/eslint-config": "file:tools/eslint/config",. Eslint might support direct file links as well so we can bypass npm entirely

@damienwebdev updated

repo: graycoreio/daffodil


text:
F-Droid build failed

The tag name is v.1.3.6 which should be v1.3.6. Could you please fix it? Thanks!

Done. Sorry about that

Thanks!

@greenart7c3 no fdroid APK for 2.0.6? ref: https://gitlab.com/fdroid/fdroiddata/-/jobs/8085503100#L970

Damm, I think I deleted the wrong file. I'll see if I can fix this when I get home

Can you try again to see if it is fixed?

yup, confirmed, thanks

authors: greenart7c3 licaon-kter linsui


text:
How to avoid blinking when switching between pages using react-router?

💬 Questions and Help
Hi,
Here is the problem:

When the page just loads, it causes blinks (or flashes) while navigating the pages. But after visiting the page for the first time it works smoothly.
How to make it work smooth always?
I tried to add webpackPrefetch: true but this doesn't help.
Here is the repo for reproduce https://github.com/ashgaliyev/react-router-loadable-components-flashing-problem

you can Component.preload() on hover of those links

@oreqizer Awesome! That's helped! Thank you! Is there a way to call preload for each component when the browser is idle?

Is there a way to call preload for each component when the browser is idle?

Don't know personally, you will probably have to implement some logic yourself. Maybe someone else will be of more help here

Preloading everything is quite opposite to the idea of code splitting.
React(experimental) itself recommends using useTransition and Suspense to deffer page change until "the new page" is ready. Refer to docs.

@oreqizer any ideas for touch devices? 🤔

@oreqizer - you can use touchstart, which will give you an extra 300ms to load the stuff.

@theKashey I tried at, but still got blinking, I'll try with prod build actually

Well, the "real" fix would be to use useTransition and Suspense from the experimental branch of React, so you will be able to "block" transition until the new page is ready.
But that's "experimental" today, and there is not much you can do.
However, you can try preventing navigation event manually and replaying it once page is ready to accept transition. Probably react-router would be not a best choice in this case.

The way I solved this is by not using loadable-components but rather React.lazy and dynamic imports
While your routes are React.lazy'd
Link to a page:
    <a
      href='/dashboard'
      onMouseEnter={() => import('pages/dashboard')} // this is like a prefetch
      onClick={(e) => {
        e.preventDefault();
        import("pages/dashboard").then(() => { // waits for import before navigating (no spinners/fallback)
          navigate("/dashboard");
        });
      }}
    />

Hope this helps

authors: ashgaliyev hjoelh olso oreqizer theKashey

repo: gregberge/loadable-components


text:
Font kerning is handled incorrectly

Here is an example of input text AaBb_- [efg]

When rendered with GIMP, it looks like this:

You can see there are various glyph placement differences.

So my "dash rendered as underscore" issue on MacOS is clearly not a Windows quirk.

Sorry, I was referring to the preview appearing blank, as a windows quirk. (Appears to be painting below a 'wx.frame')
The kerning issues are a real bug and not OS dependent.

Fixed by #39

authors: CaptClaude gregdavill

repo: gregdavill/KiBuzzard


text:
Using customBodyRender to render an MUI element causes styling in other areas to bug out

Expected Behavior
Using customBodyRender should allow one to render elements in the specified column of a datatable.
Current Behavior

When using customBodyRender, if I return a vanilla html element (button for example) all works fine and no issues occur. If I however use an MUI Button, or even an MUI switch, the rest of my page bugs out. Styles on the datatable get lost (the top right action buttons lose styling), and my apps side navigation bar loses most of its layout/styling.
Steps to Reproduce (for bugs)
Code for column that breaks:
{     name: "Column 1",     options: {         customBodyRender: (value: any, tableMeta: any, updateValue: any) => {             return (                 <Button onClick={() => console.log(value, tableMeta) }>                     Edit                 </Button>             )         }     } }
Code for column that works:
{     name: "Column 1",     options: {         customBodyRender: (value: any, tableMeta: any, updateValue: any) => {             return (                 <button onClick={() => console.log(value, tableMeta) }>                     Edit                 </button>             )         }     } }
I am importing the package as needed. I also followed the exact sample code Here and I am having the same issue.
It is also worth noting that this does not produce any errors in the console when the bug occurs.
Your Environment

Tech
Version

Material-UI
4.12.3

MUI-datatables
4.0.0

React
17.0.2

Yarn
1.22.17

browser
Chrome Version 100.0.4896.60 (Official Build) (64-bit)

After further testing, it was discovered that this is an MUI issue and is unrelated to MUI datatables.

repo: gregnb/mui-datatables


text:
missing a " ' "

fixes #

Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code docstring.
[ ] Add an entry in CHANGES.md summarizing the change and linking to the issue and your username.
[ ] Add *Version changed* or *Version added* note in any relevant docs and docstring.
[ ] Run pytest and tox, no tests failed.

Thanks! I will merge it after fixing the CI.

authors: Jeroendevr greyli

repo: greyli/apiflask


text:
NoteEvent limitation (?)

Is there any way of, in a single track, playing two notes, with different durations, simultaneously?
I mean, imagine an A4 and an E4; One whole note, the other quarter note; Both starting together. Is there any way of producing it with this API?
The same for arpeggios: is it possible to start a note before stopping the previous one?

Hi @PedroAlvesV ,
Currently it is not possible to have overlapping durations within a single track in this API; it would have to be on separate tracks.  This would be a nice feature, though I'm not sure how the API would look for that.  Do you have any ideas?
-Garrett

Yep. I was thinking about giving the user more control over it. I mean, the NoteEvent is an awesome abstraction, but, as I pointed, there's this one limitation. Maybe if the user could, by wish, set the On and Off signals, it would solve the problem. So, it would keep the NoteEvent, but also offer the usage of NoteOn and NoteOff.
Another thing that I noticed is that these classes (NoteOn and NoteOff) do exactly the same, and what they do is not even enough to justify a single whole class, from the way I see it. Also, they're used exclusively in NoteEvent:buildData() and in Track:polyModeOn().

What I would do (and probably will with LuaMidi haha):

Create a Util function to create a table like these current NoteOn/NoteOff objects (possibly "on_off_signal()" or something similar)
Rewrite NoteOn and NoteOff to let the user use them (as stated in the first paragraph)

Hi Pedro,
Good ideas.  I think I used separate classes for NoteOn and NoteOff with the thought that it would be convenient to add more functionality to them later.  You're right though, currently they're just containers for properties.
I'm thinking something like this may work to provide the ability to have two simultaneous notes with different durations, where the duration index would line up with the pitch index:
new MidiWriter.NoteEvent({pitch: ['E4','D4'], duration: ['4', '2']})

The problem, though, is how to know where the next NoteEvent will begin.
As you suggested, we could provide functions which allow you to explicitly turn on/off notes, but the user/developer would need to keep track of timing themselves though so it's just not very user friendly.  Do you have a particular need for this, or is it just something you had in mind?
-Garrett

He would have to be aware of the delta time, that's true, but most people working with MIDI frameworks do. Besides, the NoteEvent would always be available.
I have been wondering about it because I wrote a function that receives a MIDI file and creates LuaMidi objects to represent it. It works pretty fine, actually. The only thing I couldn't manage it to get, yet, is the timing, but that's because I haven't code anything this week haha
However, this overlapping functionality is somehow a basic need. Take as example Stairway to Heaven's intro. It sounds kind of chiptune or something like it, because the arpeggio sounds as if there's a hardware limitation of one note at a time.

I think in the case of Stairway to Heaven, and other similarly played sustained arpeggios, changing the note durations isn't the best approach because it becomes a bit unreadable as musical notation.  I understand that you can dial in the exact note length that way though.  The notes would still be abruptly cut off instead of trailed off.
For this case I think there should be support in this API for Controller Change events.  Then you can apply a sustain pedal as needed for the notes that should be sustained.
Looks like the status code for Control Change is Bn.  Here's a list of messages:
https://www.midi.org/specifications/item/table-3-control-change-messages-data-bytes-2
I'll take a closer look at this when I have some time and try to incorporate into MidiWriterJS.
-Garrett

Hi @PedroAlvesV,
I've added a ControllerChangeEvent class in 1.5.2 which can be used to add controller events.
track.addEvent([
	new MidiWriter.NoteEvent({pitch: ['A4'], duration: '4'}),
	new MidiWriter.ControllerChangeEvent({controllerNumber: 1, controllerValue: 127}),
	new MidiWriter.NoteEvent({pitch: ['B4'], duration: '4'}),
]);

I think whether or not the control changes are respected will depend on the player you use.  But you should now be able to add sustain pedal controls to achieve what we were discussing above.  Let me know if you have any issues.
-Garrett

I knew there was an issue somewhere I meant to comment on!
Starting one note on a channel before another ends (legato?), where the second note "chokes" the first seems often to be how slides/glissando are sequenced on 303-style hardware synths (MB-33 & clones, TT-303, x0xb0x...), probably because they tend not to have MIDI implementations sophisticated enough for controller events. Some more sophisticated synths (e.g. Behringer DeepMind 12) also use this same mechanism, the speed of the slide (or none at all) being dependant on a portamento setting.
IIRC MIDI notes on a single channel cannot overlap, so no gap is a primitive way of specifying slide.
However I have not tested this with MidiWriterJS (I am using it to algo-generate MIDI files and play them with hardware) but will give it a go and find out. Thanks!

authors: PedroAlvesV grimmdude jpw

repo: grimmdude/MidiWriterJS


text:
For base_task, task.run() will work with context if no structure is provided.

[x] I have read and agree to the contributing guidelines.

Is your feature request related to a problem? Please describe.
prompt_task = PromptTask(
    "Respond to the user's following question 'who are you' in the language '{{preferred_language}}' and tone '{{tone}}'.",
    context={"preferred_language": "ENGLISH", "tone": "PLAYFUL"},
)

if just create a task like this, the context will not filled in when prompt_task.run().
Describe the solution you'd like
the context for prompt_task work without a  structure.
in base_task.py
    @property
    def full_context(self) -> dict[str, Any]:
        if self.structure:
            structure_context = self.structure.context(self)

            structure_context.update(self.context)

            return structure_context
        else:
            return self.context

Describe alternatives you've considered
None
Additional context
None

Are you able to provide a fully reproducible example? With this example, I run into #1155 first:
from griptape.tasks import PromptTask

prompt_task = PromptTask(
    "Respond to the user's following question 'who are you' in the language '{{preferred_language}}' and tone '{{tone}}'.",
    context={"preferred_language": "ENGLISH", "tone": "PLAYFUL"},
)

prompt_task.run()

Traceback (most recent call last):
  File "/Users/collindutter/Documents/griptape/griptape-playground/src/issues/1154.py", line 8, in <module>
    prompt_task.run()
  File "/Users/collindutter/Documents/griptape/griptape/griptape/tasks/prompt_task.py", line 81, in run
    message = self.prompt_driver.run(self.prompt_stack)
                                     ^^^^^^^^^^^^^^^^^
  File "/Users/collindutter/Documents/griptape/griptape/griptape/tasks/prompt_task.py", line 48, in prompt_stack
    memory = self.structure.conversation_memory
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'conversation_memory'

Thanks!

Could not because I also run into the error, so i fix the exception myself and continued.
I just want to find the inner working of Task, if it is not supported to work alone, I could use a structure.

authors: Chuan-Zh collindutter

repo: griptape-ai/griptape


text:
CCX Download link broken.

ccx file link seems to be broken.

March 2024 and Llink is still down.

YES ITS STILL DOWN!!! ARE YOU ALIVE OVER THERE?

authors: JoelLeppe Skettalee namrrac


text:
Not scrolling when sortable items get to edge

Refer issue #52
When we drag an item to the edge, auto scroll is not happening.
But when browser default scrollbar is used autoscroll works
Try this fiddle
http://jsfiddle.net/aNh9H/615/
But this example is based on mcustomscrollbar.
Here i found the issue is due to overflow:hidden

Unfortunately I have to use overflow:hidden in order to hide native scrollbars

authors: DP-Prakash gromo


text:
Check default dashboard is no longer available

It seems a new version of Eureka has removed the default dashboard or moved to a specific path instead the root path.
Investigate what happened.

Dashboard is disabled in the config: https://github.com/groot-mg/service-discovery/blob/main/service-discovery-app/src/main/resources/application.yml#L13

repo: groot-mg/service-discovery


text:
Update 'hello' example to send vertices to GPU

Hi,
Love the idea of this library and that you include an example of it's use. The hello example works, however, I was unsuccessful getting a Vec<f64> sent to the GPU and rendered accordingly.
Is is possible to update the example to include this to minimise the guesswork users are doing? It seems to me that a more practical example would render vertices that are not hard coded in the vertex shader.
Thanks in advance!

Hi! :wave:
The easiest way to do this would be to start with Vec<f32> because usually f64s require some extra work or may not be supported at all.
glow should work similar to regular OpenGL, so any tutorials for OpenGL (e.g. https://learnopengl.com/) or WebGL should be helpful. I could help you to change the triangle example to have vertices provided from a Vec<f32> if it would be helpful though.

I would love some assistance here - I've been able to use libraries built on top of glow but I keep running into various pitfalls I'm sure could be avoided by building my own library.
I might start per your advice using f32 as the datatype, create a pull request and we can go from there.

Sounds good to me! I’d be happy to help. We could probably just copy the existing hello example and add some more interesting parts.

Not a complete example, but I'll just dump this here because it may be useful to other people
use glow::{Buffer, Context, HasContext, ARRAY_BUFFER, FLOAT, STATIC_DRAW};

/// An error with this whole object - this is tied in to the rest of my project.
#[derive(Debug)]
pub enum QuadError {
    /// Failed to upload buffer data to the GPU
    BufferCreationFailed(String),
}

/// SNIP .....

unsafe fn upload_vertex_array_f32(gl: &Context, vertices: Vec<f32>) -> Result<Buffer, QuadError> {
    let vao = gl
        .create_vertex_array()
        .map_err(QuadError::BufferCreationFailed)?;
    gl.bind_vertex_array(Some(vao));
    let vbo = gl
        .create_buffer()
        .map_err(QuadError::BufferCreationFailed)?;
    gl.bind_buffer(ARRAY_BUFFER, Some(vbo));

    gl.buffer_data_u8_slice(ARRAY_BUFFER, as_u8_slice(&vertices), STATIC_DRAW);

    Ok(vbo)
}

authors: candronikos grovesNL sdfgeoff

repo: grovesNL/glow


text:
Can't run "helloworld" example with C++ [ MacOS Yosemite 10.10.5 ]

when i run these commands
./greeter_server
I0516 23:51:50.366454000 140735199294208 server_builder.cc:247]        Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2147483647, CQ timeout (msec): 1000
Segmentation fault: 11

./greeter_client
E0516 23:52:50.960269000 140735199294208 sync_posix.c:60]              assertion failed: pthread_mutex_lock(mu) == 0
Abort trap: 6

Duplicate of #10909. The fix for now is to do a clean install of 1.2.x in which this problem does not exist. No one is actively looking into this at the moment, but it is on our radar. Closing.

authors: iceonepiece ncteisen

repo: grpc/grpc


text:
How can i have a control over Server Streaming?

Hi,
I have a scenario which is described with the following:
gRPC Version is : 1.19.0
i am streaming data from server to client by using API IServerStreamWriter.
On the Client side i am trying to read the streamed data by using IAsyncStreamReader :
while (await call.ResponseStream.MoveNext().ConfigureAwait(false))
{
......
}
Since there are no data streamed from client side, i found that i am not getting out of this loop (client side) as fast as i expected.
First Question      : Do i need to set the completeness of the streaming from the server side.
Second Question : Am i able (On the client side) to check that the streaming (ResponseStream) is Completed?
otherwise this Call call.ResponseStream.MoveNext() causes some exception, because this call tries to pick up unavailable data.
Third Question   : Is there any possibilities to define some time out for waiting the data on the client side.
I have so far checked what is provided by the API on the server side IServerStreamWriter, and on the client side IAsyncStreamReader, which it doesn't help me to achieve my Goal.
Do i need to get a new upgraded gRPC version, which could help me further?
Thanks a lot for any help.
Best regards
Anas

This form is for bug reports and feature requests only.
For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc
For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io

authors: MhdAna markdroth


text:
tests.cloud_to_cloud:c++:node_server:cancel_after_first_response timeout

Full logs: https://gist.github.com/dklempner/1764be2a17ddd293ba70

https://grpc-testing.appspot.com/job/gRPC_interop_master/2950/HTML_Report/

authors: dklempner yang-g


text:
httpcli crashes at grpc_endpoint_destroy when ssl handshake fails

I encounter this in current Pod version, provided from https://github.com/GoogleCloudPlatform/ios-docs-samples. endpoint->vtable seems to have invalid value.
I think this problem occured by following steps:

request endpoint (req->ep) passed into ssl_handshake(httpcli_security_connector.c)
handshake fails
security_handshake_done(handshake.c) called with error != GRPC_ERROR_NONE. here, req->ep  seems to be destroyed through h->wrapped_endpoint but req->ep still have non-null address
on_secure_transport_setup_done(httpcli_security_connector.c) called back with status != GRPC_SECURITY_OK
on_handshake_done(httpcli.c) called with ep == NULL
next_address(httpcli.c) called, and when req->next_address == req->addresses->naddrs, finish(httpcli.c) called
finish(httpcli.c) try to destroy endpoint again, because req->ep still has non-null address

my workaround is set NULL to req->ep when on_handshake_done(httpcli.c) called with ep == NULL.
is this bug or am I missing something to work httpcli correctly?

Several bugfixes around that part of the code have happened in the last month. Closing for now. Please re-open if this is still an issue.

authors: dgquintas umegaya


text:
Update Readme.md

Updated Python status.
Added Coverage status.

Please squash commits?

authors: jayantkolhe nathanielmanistaatgoogle


text:
Enable CFStream by default on  iOS

Enable CFStream on iOS for all wrapped languages.

Can you add a more detailed description?
Questions that come to my mind:

do we want to enable on Mac in general (for all languages in all setups?)
your PR doesn't enable cfstream for some build systems (e.g. cmake, bazel) is that intended?

@jtattermusch thanks for your comment. After discussing with Muxi we decided to enable CFStream only on iOS. CFStream will be enabled for all languages and all build systems on iOS. I'm working on updating the PR.
Bazel builds already have support for cfstream. The cc_library has a use_cfstream param. grpc_base_c sets use_cfstream = True.
I'm having some trouble with figuring out how to modify build.yaml to link against CoreFoundation library on iOS. I want to do the following: On iOS, libgrpc needs to link against -framework CoreFoundation. I'm assuming if I modify build.yaml correctly, both Makefile and CMakeLists.txt will be updated to link against CoreFoundation after running generate_projects.sh. Is that correct?
Any idea what needs to be changed in build.yaml to make libgrpc link against CoreFoundation? Thanks!

The build.yaml  compilation flags are only reflected by Makefile,  setting options for cmake needs to be done separately (somewhere in https://github.com/grpc/grpc/blob/master/templates/CMakeLists.txt.template).
if we only want to use cfstream on iOS, I'm not sure if we have a cmake use case there (we might), so this is something to check.   Btw, C# is using "make" to build iOS binaries: https://github.com/grpc/grpc/blob/master/src/csharp/experimental/build_native_ext_for_ios.sh

Thanks @jtattermusch. We don't have a cmake  usecase internally, but there might be other gRPC iOS users who use cmake. I have updated Makefile.template and CmakeLists.txt.template to link CoreFoundation lib. PTAL.

Started an adhoc artifact - packages - distribtest run https://sponge.corp.google.com/invocation?id=9d0aa1ec-a4b7-4abb-baa0-652101833b79&searchFor=

@jtattermusch  CFStream is enabled if:

#if defined(GRPC_CFSTREAM), and
environment variable grpc_cfstream is set to 1.

So, a compile time check is not sufficient.
On Mac OS:

GRPC_CFSTREAM is defined
environment variable grpc_cftstream is not set to 1 by default

On iOS:

GRPC_CFSTREAM is defined
environnment variable grpc_cfstream is set to 1 by default.

Note that applications can override the default behavior by setting the grpc_cfstream environment variable. For example cfstream_test explicitly enables CFStream on Mac OS.
CFStream enables gRPC to detect network connectivity changes while the app is in the background (POSIX sockets don't support this). All wrapped languages can benefit from this on iOS.

@jtattermusch CFStream is enabled if:

#if defined(GRPC_CFSTREAM), and
environment variable grpc_cfstream is set to 1.

So, a compile time check is not sufficient.
On Mac OS:

GRPC_CFSTREAM is defined
environment variable grpc_cftstream is not set to 1 by default

On iOS:

GRPC_CFSTREAM is defined
environnment variable grpc_cfstream is set to 1 by default.

Note that applications can override the default behavior by setting the grpc_cfstream environment variable. For example cfstream_test explicitly enables CFStream on Mac OS.
CFStream enables gRPC to detect network connectivity changes while the app is in the background (POSIX sockets don't support this). All wrapped languages can benefit from this on iOS.

Ok that's fair, thanks for the explanation.
is there a debug log message that will tell me when cfstream is enabled?

@rmstar - Now that we are confident with CFStream, can we change grpc_cfstream to a negative option grpc_disable_cfstream?

@jtattermusch if you turn on tcp tracing and DEBUG level logging you will see log lines containing the string CFStream. For example:
D0628 12:10:06.496004000 123145361362944 tcp_client_cfstream.cc:85]    CLIENT_CONNECT :0x7fe0a3f6d710 OnAlarm, error:0x4
D0628 12:10:06.496123000 123145361362944 endpoint_cfstream.cc:257]     CFStream endpoint:0x7fe083c06cf0 read (0x7fe085802a10, 0x7fe0858029c0) length:0
D0628 12:10:06.503668000 123145361362944 cfstream_handle.cc:63]        CFStream ReadCallback (0x7fe0a3f6aa30, 0x7fe0a3f6ed50, 2, 0x7fe0a3f6aa30)

@muxi I can look into changing grpc_cfstream to grpc_disable_cfstream in a followon PR.
On iOS, we would disable CFStream using setenv("grpc_disable_cfstream", "1");. That looks good.
However, to enable CFStream on Mac OS, we would need to do: setenv("grpc_disable_cfstream", "0");. IMO that looks a bit awkward because of the double negation. We don't that issue when the environment variable is named grpc_cfstream. WDYT?

I see that your adhoc artifact - packages - distribtest run failed due to tool failure. I'm not familiar with this test - is the failure unrelated to my change?

No you don't do it that way :)  grpc_disable_cfstream=0 will be default and only if the user want to disable CFStream will they use grpc_disable_cfstream=1. So on both platforms and all languages CFStream will be enabled by default; only be disabled on demand.

New adhoc build: https://sponge.corp.google.com/invocation?id=6ca50109-6201-49f2-b82a-dea9553e961c&searchFor=

authors: jtattermusch muxi rmstar


text:
Move ~grpc_server_security_connector() = default to .cc file

When the implementation is in the header file, there's an "incomplete type" error caused by grpc_server_credentials.
Compiling with clang version 11.0.0 (https://github.com/llvm/llvm-project.git 8697d443ab24d1652d09393efca768cdf4c22b39), Target: x86_64-apple-darwin19.4.0
through cmake's add_subdirectory( lib/grpc ) in a parent project
[...] Building CXX object lib/grpc/CMakeFiles/grpc.dir/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc.o
FAILED: lib/grpc/CMakeFiles/grpc.dir/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc.o
/usr/local/opt/llvm/latest/bin/clang++  -DCARES_STATICLIB -D__CLANG_SUPPORT_DYN_ANNOTATION__ -I../../lib/grpc/third_party/zlib -I../../lib/grpc/include -I../../lib/grpc -I../../lib/grpc/third_party/address_sorting/include -I../../lib/grpc/third_party/boringssl-with-bazel/src/include -I../../lib/grpc/src/core/ext/upb-generated -I../../lib/grpc/third_party/upb -Ilib/grpc/third_party/zlib -Ilib/grpc/third_party/cares/cares -I../../lib/grpc/third_party/cares/cares -I../../lib/grpc/third_party/abseil-cpp -stdlib=libc++ -nostdinc++ -ibuiltininc -I /usr/local/opt/llvm/latest/include/c++/v1 -fcxx-exceptions -fassociative-math -freciprocal-math -march=native -mtune=native -fforce-emit-vtables -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.15 -fPIC -std=c++2a -MD -MT lib/grpc/CMakeFiles/grpc.dir/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc.o -MF lib/grpc/CMakeFiles/grpc.dir/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc.o.d -o lib/grpc/CMakeFiles/grpc.dir/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc.o -c ../../lib/grpc/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc
In file included from ../../lib/grpc/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.cc:21:
In file included from ../../lib/grpc/src/core/lib/security/credentials/tls/grpc_tls_credentials_options.h:28:
In file included from ../../lib/grpc/src/core/lib/gprpp/ref_counted.h:36:
../../lib/grpc/src/core/lib/gprpp/ref_counted_ptr.h:103:34: error: member access into incomplete type 'grpc_server_credentials'
if (value_ != nullptr) value_->Unref();
^
../../lib/grpc/src/core/lib/security/security_connector/security_connector.h:154:3: note: in instantiation of member function 'grpc_core::RefCountedPtr<grpc_server_credentials>::~RefCountedPtr' requested here
~grpc_server_security_connector() override = default;
^
../../lib/grpc/include/grpc/grpc_security.h:465:16: note: forward declaration of 'grpc_server_credentials'
typedef struct grpc_server_credentials grpc_server_credentials;

@yashykt

Fixing  EasyCLA email address issue, irrelevant to the pull request

The CLA check is still failing.  We can't look at this code until that passes.

I'll try closing and re-opening the PR.

@markdroth Seems to be working now. Do you need me to rebase onto head? The change is trivial, moving the (default) definition from the header to the implementation file.

It's not clear to me what's causing this problem or why this fix helps, but the change itself seems fine.  Let's see if the tests are happy.

@markdroth Right, I'm not sure about the incomplete type at that point, could very well be a recent LLVM thing -- maybe https://reviews.llvm.org/D79945 ? -- but since the change should make no functional or performance difference... :)

This looks good to me.  @yihuazhang, can I get a second review from you?  Once you approve, I'll go ahead and merge.

authors: kedartal markdroth


text:
connection refused when running init -upgrade with provider cache

Describe the bug
Running terragrunt init -upgrade with TERRAGRUNT_PROVIDER_CACHE=1 fails in CI due to refused connection.
Steps To Reproduce
That's tricky. I could not reproduce in a minimal example. This only seems to happen in our production setup.
export TERRAGRUNT_PROVIDER_CACHE=1

  function print_warn() {
      echo -e "\033[0;33mWARN: $1\033[0m"
  }

  for DIR in $(find ${{ inputs.dir }} -name '.terraform.lock.hcl' ! -path '*/.terragrunt-cache/*' -exec dirname {} \; | sort); do
    if (grep -q -e "^\s*skip\s*=\s*true$" $DIR/terragrunt.hcl); then
      print_warn "Skipping $DIR: 'skip = true' in terragrunt.hcl"
    else
      echo "DIR: $DIR"
      if ! (terragrunt init -upgrade --terragrunt-working-dir $DIR --terragrunt-log-level debug); then
        print_warn "Failed to init terragrunt in $DIR"
        print_warn "Deleting .terraform.lock.hcl and retry"
        rm -f $DIR/.terraform.lock.hcl
        terragrunt init -upgrade --terragrunt-working-dir $DIR --terragrunt-log-level debug
      fi
      terragrunt providers lock -platform=darwin_amd64 -platform=linux_amd64 -platform=darwin_arm64 --terragrunt-working-dir $DIR --terragrunt-log-level debug
    fi
  done

The error:
│ Error: Failed to resolve provider packages
│
│ Could not resolve provider hashicorp/time: could not query provider
│ registry for registry.opentofu.org/hashicorp/time: the request failed after
│ 2 attempts, please try again later: Get
│ "http://127.0.0.1:44237/v1/providers//registry.opentofu.org/hashicorp/time/versions":
│ dial tcp 127.0.0.1:44237: connect: connection refused

Expected behavior
Terragrunt starts the cache server and is able to serve providers from there.
Nice to haves

[x] Logs are attached
10_Lock Providers (._projects-team-interactive) _ Lock Providers.txt

Versions

Terragrunt version: 0.58.3
OpenTofu version: 1.7.0
Environment details (Ubuntu 20.04, Windows 10, etc.): Github Action Runner, based on Ubuntu 22.04

Additional context
I'm sorry I can't provide a reproducible example. Hopefully the logs are helpful.

I just tried run-all instead:
export TERRAGRUNT_PROVIDER_CACHE=1
export TERRAGRUNT_PARALLELISM=5
terragrunt run-all init -upgrade --terragrunt-working-dir ${{ inputs.dir }}
terragrunt run-all providers lock -platform=darwin_amd64 -platform=linux_amd64 -platform=darwin_arm64 --terragrunt-working-dir ${{ inputs.dir }}

with the same result

Hi @norman-zon, thanks for the full log, it's really helpful.
We are still working on improving Terragrunt Provider Cache, so critical errors in the logs are not yet obvious enough.
You receive the error connect: connection refused because the cache server was unable to verify the signature of some providers.
2024-05-07T12:48:14.4368305Z time=2024-05-07T12:48:14Z level=error msg=tofu invocation failed in /home/runner/_work/terraform-projects/terraform-projects/projects-team-interactive/base/environments/production/.terragrunt-cache/WDfGuyxxnvdter3UCVGXKlJ7Ylc/OuHMLorwoQH1IrPrCjcWG7kWxUQ prefix=[projects-team-interactive/base/environments/production]
2024-05-07T12:48:14.4370690Z time=2024-05-07T12:48:14Z level=error msg=1 error occurred:
2024-05-07T12:48:14.4371255Z 	* authentication signature from unknown issuer

This is most likely due to the fact that by default terragrunt now uses tofu, and unless you explicitly specify a registry host in the source, tofu downloads them from its own registry where some provider has an invalid signature.
There are two ways to solve the issue:

Using terraform TERRAGRUNT_TFPATH=terraform
Explicitly specifying the registry host:

terraform {
  required_providers {
    fastly = {
      source  = "registry.terraform.io/fastly/fastly"
    }
  }
}

@norman-zon, one more, please do not close this issue. I will change the behavior of signature verification so that it does not lead to a critical error, but only a notification.

@levkohimins I do use tofu on purpose.
Also I noticed the warnings about the provider signatures. But I wonder why this happens for hashicorp owned providers, like  hashicorp/time in my example above:
"http://127.0.0.1:44237/v1/providers//registry.opentofu.org/hashicorp/time/versions":
dial tcp 127.0.0.1:44237: connect: connection refused

Furthermore when trying to recreate the behaviour in a minimal example and only using hashicorp/time, no other providers, no modules, the caching worked:
3_Lock TG providers.txt

@levkohimins I do use tofu on purpose. Also I noticed the warnings about the provider signatures. But I wonder why this happens for hashicorp owned providers, like hashicorp/time in my example above:
"http://127.0.0.1:44237/v1/providers//registry.opentofu.org/hashicorp/time/versions":
dial tcp 127.0.0.1:44237: connect: connection refused

Furthermore when trying to recreate the behaviour in a minimal example and only using hashicorp/time, no other providers, no modules, the caching worked: 3_Lock TG providers.txt

I didn't find any errors in your logs. But in any case, as I said earlier, use the full path in the source attribute registry.terraform.io/*/* to force tofu to use the providers from the terraform registry, or wait until this issue is fixed.

I'm a little confused.
The error I am seeing is connection refused for  hashicorp/time. I don't understand how this is connected to the missing provider signatures.
Here is an example debug-log of a run using hashicorp/time and ns1-terraform/ns1, which is not signed, as the log indicates. But this still does not cause a connection refused error, although having provider cache enabled.
This leads me to believe the cause for the connection refused is not the missing signature.

The cache server is responsible for verifying the signature. At the moment, if the signature can't be verified, it fails with an error authentication signature from unknown issuer, which is what I'm going to fix.
The signature is checked only for providers that have not yet been cached, so the error does not occur if the provider has been cached previously.
When the cache server is not available Terraform returns an error connection refused.

Hi @norman-zon, Could you confirm that the issue has been resolved?

@levkohimins, sorry for the late feedback. I was out of office. Can confirm it works now. Thanks a lot!

authors: levkohimins norman-zon

repo: gruntwork-io/terragrunt