text:
Toolchain property compatibility check failure in 6.8 for compileGroovy

Expected Behavior
Toolchains can be used with project that uses Groovy without losing support for IntelliJ automatically detecting the JVM level for sources.
Current Behavior
Trying to use toolchains (to control build environment) and sourceCompatibility (to support IntelliJ detecting JVM level) fails for Groovy when using sourceCompatibility. IdeaProject.languageLevel could possibly be used but the docs discourage it
https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.idea.model.IdeaProject.html#org.gradle.plugins.ide.idea.model.IdeaProject:languageLevel
Context
This was working in 6.7, but stopped working in 6.8.
Configuration is here: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/master/gradle/java.gradle#L42
It seems to be intentional in #14850. But because of it, I don't see how to have an easy-to-use build where IntelliJ detects the JVM level correctly without using IdeaProject.languageLevel - is this intended usage when using toolchains?
Steps to Reproduce
I think the issue is relatively obvious but this would repo if you need
git clone https://github.com/anuraaga/opentelemetry-java-instrumentation.git
cd opentelemetry-java-instrumentation
git fetch origin gradle-6.8
git checkout gradle-6.8
./gradlew :testing-common:compileGroovy

Fails with
Caused by: org.gradle.api.InvalidUserDataException: The new Java toolchain feature cannot be used at the project level in combination with source and/or target compatibility
        at org.gradle.api.plugins.JavaBasePlugin.checkToolchainAndCompatibilityUsage(JavaBasePlugin.java:346)
        at org.gradle.api.plugins.JavaBasePlugin.lambda$determineCompatibility$8(JavaBasePlugin.java:336)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:452)
        at org.gradle.internal.extensibility.ConventionAwareHelper$2.doGetValue(ConventionAwareHelper.java:82)
        at org.gradle.internal.extensibility.ConventionAwareHelper$MappedPropertyImpl.getValue(ConventionAwareHelper.java:128)
        at org.gradle.internal.extensibility.ConventionAwareHelper.getConventionValue(ConventionAwareHelper.java:110)
        at org.gradle.api.tasks.compile.GroovyCompile_Decorated.getSourceCompatibility(Unknown Source)
        at jdk.internal.reflect.GeneratedMethodAccessor619.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode$BeanPropertyValue$1$1.create(AbstractNestedRuntimeBeanNode.java:77)
        at org.gradle.internal.deprecation.DeprecationLogger.whileDisabled(DeprecationLogger.java:236)
        at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode$BeanPropertyValue$1.get(AbstractNestedRuntimeBeanNode.java:73)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:167)

Your Environment

Build scan URL: https://gradle.com/s/rehgrrtzcjycq

There is a confusion there I believe.
If you leverage toolchains, you indeed cannot use sourceCompatibility in the java extension. But the java version that the toolchain represents will be visible to IntelliJ during import which should result in the right language level selected.
Can you try this setup?
And if does not work update your reproducer with what you tried and what you expect to see in the IDE.

There is a confusion there I believe.
If you leverage toolchains, you indeed cannot use sourceCompatibility in the java extension. But the java version that the toolchain represents will be visible to IntelliJ during import which should result in the right language level selected.
Can you try this setup?
And if does not work update your reproducer with what you tried and what you expect to see in the IDE.

@ljacomet Ok I will try to investigate a bit. I had a report on Slack that after removing those, IntelliJ stopped working until restoring in a different repo here - https://github.com/gradle/gradle/issues/15752. I didn't personally reproduce it though.

But the java version that the toolchain represents will be visible to IntelliJ during import which should result in the right language level selected.

One question, did you mean the version of the options.release flag? The toolchain version can't be used since you may use a newer JDK to target older bytecode.

@ljacomet Ok I will try to investigate a bit. I had a report on Slack that after removing those, IntelliJ stopped working until restoring in a different repo here - https://github.com/gradle/gradle/issues/15752. I didn't personally reproduce it though.

But the java version that the toolchain represents will be visible to IntelliJ during import which should result in the right language level selected.

One question, did you mean the version of the options.release flag? The toolchain version can't be used since you may use a newer JDK to target older bytecode.

One question, did you mean the version of the options.release flag? The toolchain version can't be used since you may use a newer JDK to target older bytecode.

In that case, you can specify the sourceCompatibility at the compilation task level and still use toolchains to get the JDK.

One question, did you mean the version of the options.release flag? The toolchain version can't be used since you may use a newer JDK to target older bytecode.

In that case, you can specify the sourceCompatibility at the compilation task level and still use toolchains to get the JDK.

Closing as there is nothing to change in Gradle.
Please add more information if you think the information provided does not resolve the issue.

Closing as there is nothing to change in Gradle.
Please add more information if you think the information provided does not resolve the issue.

authors: anuraaga ljacomet


text:
Stopping MessageHub hangs indefinitely on OutOfMemoryError

Expected Behavior
If there was some failure during tests, Gradle does not hang indefinitely but cleanly fails.
Current Behavior
After there was an OutOfMemoryError, the test task is hanging indefinitely until manually cancelled.
This is most probably not on any average OutOfMemoryError error.
We had - considering just the effect, not the cause - the same problem in older Gradle versions too.
It did not happen on an arbitrarily enforced OutOfMemoryError by just consuming all heap in a test.
But it it happens somewhere while running CDI tests using weld-junit4 with some unsatisfied dependencies.
I did not intend this short summary as a way to reproduce the issue, as I don't know how to reliably reproduce the error outside our big proprietary build, or even just outside the CI server.
In the past this was caused by a CountDownLatch that was not always counted down in certain situations, which was fixed in Gradle 7.2 with commit 7bcc1f140b5 that removed this latch.
Now with Gradle 7.5.1 the same failure situation still causes Gradle to hang indefinitely, just at a different spot.
The "Test worker" thread is trying to stop the message hub backed object connection but that does not finish while waiting Integer.MAX_VALUE seconds for the termination.
Here the thread dump for this thread:
"Test worker" #1 prio=5 os_prio=0 cpu=16343.51ms elapsed=35145.49s tid=0x00007f408403f000 nid=0x8563a waiting on condition  [0x00007f408955e000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
	- parking to wait for  <0x00000000e16d4ee8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:2123)
	at java.util.concurrent.ThreadPoolExecutor.awaitTermination(java.base@11.0.11/ThreadPoolExecutor.java:1454)
	at org.gradle.internal.concurrent.ManagedExecutorImpl.stop(ManagedExecutorImpl.java:87)
	at org.gradle.internal.concurrent.DefaultExecutorFactory$TrackedManagedExecutor.stop(DefaultExecutorFactory.java:96)
	at org.gradle.internal.concurrent.ManagedExecutorImpl.stop(ManagedExecutorImpl.java:77)
	at org.gradle.internal.remote.internal.hub.MessageHub.stop(MessageHub.java:225)
	at org.gradle.internal.concurrent.CompositeStoppable.stop(CompositeStoppable.java:106)
	- locked <0x00000000fff1d6e0> (a org.gradle.internal.concurrent.CompositeStoppable)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection.stop(MessageHubBackedObjectConnection.java:150)
	at org.gradle.internal.concurrent.CompositeStoppable.stop(CompositeStoppable.java:106)
	- locked <0x00000000fff0ff00> (a org.gradle.internal.concurrent.CompositeStoppable)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:137)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)

The thread it is waiting on according to naming pattern is this one:
"/127.0.0.1:40264 to /127.0.0.1:45539 workers Thread 3" #15 prio=5 os_prio=0 cpu=28.92ms elapsed=41873.28s tid=0x00007f4085e00800 nid=0x85653 runnable  [0x00007f40466db000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait(java.base@11.0.11/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.11/EPollSelectorImpl.java:120)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.11/SelectorImpl.java:124)
	- locked <0x00000000e16cbb48> (a sun.nio.ch.Util$2)
	- locked <0x00000000e16cb908> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@11.0.11/SelectorImpl.java:141)
	at org.gradle.internal.remote.internal.inet.SocketConnection$SocketInputStream.read(SocketConnection.java:185)
	at com.esotericsoftware.kryo.io.Input.fill(Input.java:146)
	at com.esotericsoftware.kryo.io.Input.require(Input.java:178)
	at com.esotericsoftware.kryo.io.Input.readByte(Input.java:295)
	at org.gradle.internal.serialize.kryo.KryoBackedDecoder.readByte(KryoBackedDecoder.java:88)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
	at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:81)
	at org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:270)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)

The process on port 40264 is the worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 51' process.
The process on port 45539 is the org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.5.1 process.
So it seems that executor task tries to read one byte from this IPC connection but the byte is never delivered and thus it hangs forever and the executor cannot cleanly shut down which is waited for though.
Gradle version
7.5.1

Here the four threads from the Gradle daemon side:
"/127.0.0.1:45539 to /127.0.0.1:40264 workers" #958 prio=5 os_prio=0 cpu=0.52ms elapsed=41874.43s tid=0x00007fa3fc032000 nid=0x8564d waiting on condition  [0x00007fa3bca1e000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
	- parking to wait for  <0x000000078c905528> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@11.0.11/LockSupport.java:194)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.11/AbstractQueuedSynchronizer.java:2081)
	at org.gradle.internal.remote.internal.hub.queue.EndPointQueue.take(EndPointQueue.java:49)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:403)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)

"/127.0.0.1:45539 to /127.0.0.1:40264 workers Thread 2" #959 prio=5 os_prio=0 cpu=2.28ms elapsed=41874.43s tid=0x00007fa3f084c800 nid=0x8564e waiting on condition  [0x00007fa3bc71b000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
	- parking to wait for  <0x000000078c905ae0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@11.0.11/LockSupport.java:194)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.11/AbstractQueuedSynchronizer.java:2081)
	at org.gradle.internal.remote.internal.hub.queue.EndPointQueue.take(EndPointQueue.java:49)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:403)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)

"/127.0.0.1:45539 to /127.0.0.1:40264 workers Thread 3" #960 prio=5 os_prio=0 cpu=0.66ms elapsed=41874.43s tid=0x00007fa3f0851000 nid=0x8564f waiting on condition  [0x00007fa3a96fd000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
	- parking to wait for  <0x000000078c90aec8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@11.0.11/LockSupport.java:194)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.11/AbstractQueuedSynchronizer.java:2081)
	at org.gradle.internal.remote.internal.hub.queue.EndPointQueue.take(EndPointQueue.java:49)
	at org.gradle.internal.remote.internal.hub.MessageHub$ConnectionDispatch.run(MessageHub.java:322)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)

"/127.0.0.1:45539 to /127.0.0.1:40264 workers Thread 4" #961 prio=5 os_prio=0 cpu=30.80ms elapsed=41874.43s tid=0x00007fa3f046f800 nid=0x85650 runnable  [0x00007fa3ca8b7000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPoll.wait(java.base@11.0.11/Native Method)
	at sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.11/EPollSelectorImpl.java:120)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.11/SelectorImpl.java:124)
	- locked <0x000000078c906248> (a sun.nio.ch.Util$2)
	- locked <0x000000078c906008> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(java.base@11.0.11/SelectorImpl.java:141)
	at org.gradle.internal.remote.internal.inet.SocketConnection$SocketInputStream.read(SocketConnection.java:185)
	at com.esotericsoftware.kryo.io.Input.fill(Input.java:146)
	at com.esotericsoftware.kryo.io.Input.require(Input.java:178)
	at com.esotericsoftware.kryo.io.Input.readByte(Input.java:295)
	at org.gradle.internal.serialize.kryo.KryoBackedDecoder.readByte(KryoBackedDecoder.java:88)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
	at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:81)
	at org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:270)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)

Most interesting imho is the last one, that also waits for an incoming byte on the IPC connection.
So both processes wait for a byte from the other side and thus do not continue.

Thank you for providing a valid reproducer.
The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

source: gharchive/issue

authors: Vampire jbartok

repo: gradle/gradle

license_type: permissive

license_source: github-api


text:
uploadArchives task tries to publish generated POM twice

uploadArchives task tries to publish generated POM (maybe not only POM) twice
Expected Behavior
It should publish artifacts only once
Current Behavior
It dies on second attempt due to 409 (Conflict)
Context
Just trying to publish my project to corporate artifactory
Steps to Reproduce (for bugs)
As sample project
Link
As snippet
publish-jars.gradle:
task sourcesJar(type: Jar) {
    classifier = 'sources'
    from sourceSets.main.allSource
}

build.dependsOn(sourcesJar)

artifacts {
    archives sourcesJar
}

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: 'releases repo') {
                authentication(
                    userName: rootProject.properties.get('artifactory.username'),
                    password: rootProject.properties.get('artifactory.token')
                )
            }

            snapshotRepository(url: 'snapshots repo') {
                authentication(
                    userName: rootProject.properties.get('artifactory.username'),
                    password: rootProject.properties.get('artifactory.token')
                )
            }
        }
    }
}

def installer = install.repositories.mavenInstaller
def deployer = uploadArchives.repositories.mavenDeployer

[installer, deployer]*.pom*.whenConfigured { pom ->
    pom.project {
        packaging 'jar'
    }

    pom.withXml {
        asNode().dependencies.'*'.each {
            if (it.scope*.value != null) {
                it.scope*.value = 'compile'
            }
        }

        asNode().dependencyManagement.dependencies.'*'.each {
            if (it.scope*.value != null) {
                it.scope*.value = 'compile'
            }
        }

        def repos = asNode().appendNode('repositories')

        project.repositories.findAll { it.name != 'MavenLocal' }.each {
            def repo = repos.appendNode('repository')
            repo.appendNode('id', it.name)
            repo.appendNode('name', it.name)
            repo.appendNode('url', it.url)
        }
    }

    if (project.hasProperty('pomConfigurer')) {
        pom.withXml(pomConfigurer)
    }
}

install.dependsOn build
uploadArchives.dependsOn build

task 'publish-snapshot'() {
    dependsOn uploadArchives
}

task publish() {
    dependsOn uploadArchives
}

Module with POM (parent):
dependencyManagement {
    generatedPomCustomization {
        enabled = true
    }
}

ext.pomConfigurer = {
    // some pom configuration
}

Root build.gradle:
allprojects {
  apply plugin: 'maven'
  apply plugin: 'io.spring.dependency-management'
}

subprojects {
  apply from: file('publish-jars.gradle')
}

Output:
> Task :my-project:parent:uploadArchives
Could not transfer artifact groupname:parent:pom:2.1.1-rc20 from/to remote (https://releases repo): Failed to transfer file: https://releases repo/groupname/parent/2.1.1-rc20/parent-2.1.1-rc20.pom. Return code is: 409, ReasonPhrase: Conflict.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':my-project:parent:uploadArchives'.
> Could not publish configuration 'archives'
   > Failed to deploy artifacts: Could not transfer artifact groupname:parent:pom:2.1.1-rc20 from/to remote (https://releases repo): Failed to transfer file: https://releases repo/groupname/parent/2.1.1-rc20/test-parent-2.1.1-rc20.pom. Return code is: 409, ReasonPhrase: Conflict.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 22s

Your Environment
Tested on TeamCity (rhel7) and local machine with Gentoo.
Tested with gradle versions (through gradlew): 3.5, 4.2
Dependency management plugin (don't really think that it causes problems, but still): 1.0.1.RELEASE

Thanks for providing code snippets. Could you please provide a sample project on GitHub that can directly execute?

@bmuschko, Sorry for long reply (weekend after all 😄  ). Here is sample project where this bug reproduces: click

Any progress on this?

@saksmt Thanks for providing the sample project! I've cloned it and can reproduce the bug locally. Can you please describe your use case? It looks like you want to publish a BOM from the pom subproject, correct? However, it looks like it (accidentally?) also publishes a sources JAR.

I've looked into this a bit further. Here's what actually happens:

The first upload actually transfers the project's jar file
The second upload attempts to overwrite the just uploaded file with the generated POM

The documented way to set the packaging is on the MavenPom object:

Note: groupId, artifactId, version, and packaging should always be set directly on the pom object.

However, setting it to pom like in the following example does not work. The packaging will actually get overridden with the type (extension) of the first artifact without a classifier (usually jar, war etc.).
[installer, deployer]*.pom {
    packaging = 'pom'
}

Thus, it looks like the use case of uploading a POM without any artifacts was never really considered or supported.

Yeah, that's actually is my use-case - generation of parent POM/BOM, but that code is actually is in multi-module project which inherits common behavior of publishing jars and sources, which in my opinion should not be blocker for modifying original POM to have pom packaging and I could not find a way to overcome this issue...

The maven plugin (together with the core uploadArchives) are being replaced by the maven-publish plugin. As such, we don't plan on making changes to improve the (now legacy) MavenInstaller or MavenDeployer. Please switch your projects to use the maven-publish plugin, letting us know if there is something missing that prevents you from migrating.
Expect to see the legacy types deprecated in Gradle 6.x, for possible removal in Gradle 7.0.

authors: bigdaz bmuschko marcphilipp saksmt


text:
Add displayName and description to PluginDeclaration and use it in plugin-publish plugin

By specifying displayName and description in PluginDeclaration, users can avoid configuring plugins in the pluginsBundle block except if they want to use different tags or a different version for some plugins.

Reopening because plugin-publish part is still missing.


text:
Use server-api as dependency

As suggested by https://youtrack.jetbrains.com/issue/TW-73943

@bot-gradle test and merge

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

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

source: gharchive/pull-request

authors: blindpirate bot-gradle


text:
Allow Tooling API to emit different event types for test assertion an…

Specification: https://docs.google.com/document/d/195rpV9e6xQOdsPRZgleSZ_C4L9WTzXg5ATRo8Uq_OZc/edit#
Post-merge tasks:

[ ] Adjust broken test-retry plugin and re-enable TestRetryPluginSmokeTest.groovy.

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

@bot-gradle test RFM

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

@bot-gradle test and merge

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

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

Pre-tested commit build failed.

@bot-gradle test and merge

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

Pre-tested commit build failed.

@bot-gradle test rfm

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test rfm

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test rfm

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

authors: bot-gradle donat


text:
Update documentation in JavaCompile to suggest configureEach {}

Context
This javadoc is quite central. It should suggest using configureEach { } for configuring all tasks of the JavaCompile
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

@bot-gradle test and merge

No milestone for this PR. Please set a milestone and retry.

@bot-gradle test and merge

Error while scheduling pre-tested commit, please contact the administrator.

@bot-gradle test and merge

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

authors: bot-gradle jjohannes jvandort


text:
Deprecate the DependencyFactory class for removal in Gradle 8.0.

Fixes #21886

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

the changes to remove the static imports seem a bit extraneous.

I needed to use the FQN instead of an import so I could suppress deprecation warnings, back when there was no DependencyFactoryInternal and I was referencing the deprecated DependencyFactory.
They do look extraneous now, I'll revert them.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@octylFractal - Is DependencyClassPathNotationConverter#create(DependencyFactoryInternal.ClassPathNotation) missing a case for LOCAL_GROOVY?
The Gretty 4.x smoke test is failing locally for me with:
Execution failed for task ':appBeforeIntegrationTest'.
> Cannot convert the provided notation to an object of type Dependency: LOCAL_GROOVY.
  The following types/formats are supported:
    - String or CharSequence values, for example 'org.gradle:gradle-core:1.0'.
    - Maps, for example [group: 'org.gradle', name: 'gradle-core', version: '1.0'].
    - FileCollections, for example files('some.jar', 'someOther.jar').
    - Projects, for example project(':some:project:path').
    - ClassPathNotation, for example gradleApi().

  Comprehensive documentation on dependency notations is available in DSL reference for DependencyHandler type - if you are so inclined.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle cancel

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

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

Pre-tested commit build failed.

@bot-gradle test and merge

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

authors: bot-gradle tresat


text:
Implement lifecycle.allprojects draft

https://github.com/gradle/gradle/issues/29187

@bot-gradle test this without pts

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test without pts

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test without pts

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test without pts

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build


text:
fix: reintroduce login duration

Description
Many months ago, I added support for login_maximum_inactive_lifetime_duration and login_maximum_lifetime_duration in https://github.com/grafana-operator/grafana-operator/pull/345. It was quite important to have this functionality since grafana still doesn't fully track validity of OIDC sessions, which leads to forwarding stale tokens to data sources unless the right settings are made in both grafana and Keycloak. - Other parameters login_maximum_lifetime_days and login_maximum_inactive_lifetime_days, don't give enough flexibility in the period of time.
Haven't used grafana-operator since I changed companies. Recently, I rebuilt a local lab with a fresh grafana-operator, and noticed today that grafana was sending stale tokens, which shouldn't have been the case since I had all the right settings in place from previous labs.
Further digging showed that the configmap generated by grafana-operator did not contain  login_maximum_inactive_lifetime_duration and login_maximum_lifetime_duration. In source code, those get added to a struct, but not dumped into grafana.ini.
The suggested change brings back full support for the parameters.
P.S. Please, let me know if tests are needed. I haven't explored that side, though I guess it all should be doable in a timely manner.
Type of change

[X] Bug fix (non-breaking change which fixes an issue)

Checklist

[X] I have added a test case that will be used to verify my changes

Verification steps

Add the following settings to grafana CR:

      auth:
        login_maximum_inactive_lifetime_duration: 4h
        login_maximum_lifetime_duration: 8h

You should see those settings in the cm with grafana.ini:

apiVersion: v1
data:
  grafana.ini: |+
[...]
    [auth]
    login_maximum_inactive_lifetime_duration = 4h
    login_maximum_lifetime_duration = 8h

There is a risk that they disappeared during version 4 release, we did a few human errors on that one...
It would of course be great if you can add a test for it @weisdd .

@NissesSenap Was happy to help :)

authors: NissesSenap weisdd

repo: grafana-operator/grafana-operator


text:
Add github action release process for @grafana/llm

Pending close and deploy of #235, which will hopefully happen March 11, we should work on a deploy process through github actions for the @grafana/llm npm package.

Resolved in https://github.com/grafana/grafana-llm-app/pull/270

repo: grafana/grafana-llm-app


text:
Chore: add react-router to package.json

This PR adds react-router as a dev dependency for plugin scaffolding. Related to grafana/grafana/pull/33775

Ah yeah, wrong repo! 🤦
I think it'll come down the pipe via grafana-ui right now for apps as we're using the Link component there.

repo: grafana/grafana-starter-panel


text:
Remove NewPossibleNonCounterInfo until it can be made more efficient

According to benchmarks, this is very inefficient for many rate queries, temporarily removing until we find a better way.
With before as without the removed code, and after as with:
goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
                                                  │ BenchmarkRangeQuery_before.txt │    BenchmarkRangeQuery_after.txt     │
                                                  │             sec/op             │   sec/op     vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                      15.33m ± 2%   89.57m ± 3%  +484.36% (p=0.000 n=10)

                                                  │ BenchmarkRangeQuery_before.txt │      BenchmarkRangeQuery_after.txt      │
                                                  │              B/op              │     B/op       vs base                  │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                     4.946Mi ± 0%   66.805Mi ± 0%  +1250.79% (p=0.000 n=10)

                                                  │ BenchmarkRangeQuery_before.txt │    BenchmarkRangeQuery_after.txt     │
                                                  │           allocs/op            │  allocs/op   vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-16                      105.4k ± 0%   806.3k ± 0%  +665.22% (p=0.000 n=10)

I compared commit 156222cc5, before annotations were added, with this PR, commit 7756556eb:
goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
                                                 │   before    │               after                │
                                                 │   sec/op    │   sec/op     vs base               │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   29.82m ± 3%   38.52m ± 3%  +29.19% (p=0.002 n=6)

                                                 │    before    │                 after                  │
                                                 │     B/op     │     B/op       vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   378.8Ki ± 0%   5063.3Ki ± 0%  +1236.53% (p=0.002 n=6)

                                                 │   before    │                 after                  │
                                                 │  allocs/op  │   allocs/op    vs base                 │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   5.356k ± 0%   105.365k ± 0%  +1867.24% (p=0.002 n=6)

12x more garbage does not seem acceptable to me, so I pushed another commit which eliminates it in the case there is nothing to report.
goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/promql
cpu: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
                                                 │   before    │               after               │
                                                 │   sec/op    │   sec/op     vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   29.82m ± 3%   31.06m ± 1%  +4.17% (p=0.002 n=6)

                                                 │    before    │               after                │
                                                 │     B/op     │     B/op      vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   378.8Ki ± 0%   368.1Ki ± 0%  -2.84% (p=0.002 n=6)

                                                 │   before    │               after               │
                                                 │  allocs/op  │  allocs/op   vs base              │
RangeQuery/expr=rate(a_hundred[1m]),steps=1000-4   5.356k ± 0%   5.258k ± 0%  -1.83% (p=0.002 n=6)

The 4.17% extra CPU comes from Metric.Get(labels.MetricName), which can also be eliminated, but I wanted to do the minimum to get to a reasonable state.

Thank you! I added a commit to further avoid creating empty annotations, and created a PR with the same changes for the new prometheus release (benchmark details there): https://github.com/grafana/mimir-prometheus/pull/547

authors: bboreham zenador

repo: grafana/mimir-prometheus


text:
pyroscope_cli: README.md: Fix typo pyrsocope -> pyroscope

Makes copy/paste easier if it's fixed.

 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 olofj

repo: grafana/pyroscope-rs


text:
Autodetection of binary release broken for LLVM 11 on Debian 10

On a Debian WSL installation:
∵ uname -a
Linux matildaii 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 GNU/Linux
∵ cat /etc/debian_version
10.7

With this repository included at HEAD, and the declaration:
llvm_toolchain(
    name = "llvm_toolchain",
    llvm_version = "11.0.0",
)

I get the following build error:
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
        File "/home/cceckman/.cache/bazel/_bazel_cceckman/a5e80b41158b1330576b4d583ae56185/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 110, column 37, in llvm_toolchain_impl
                _download_llvm_preconfigured(rctx)
        File "/home/cceckman/.cache/bazel/_bazel_cceckman/a5e80b41158b1330576b4d583ae56185/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 177, column 13, in download_llvm_preconfigured
                fail("Unknown LLVM release: %s\nPlease ensure file name is correct." % basename)
Error in fail: Unknown LLVM release: clang+llvm-11.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz

LLVM didn't cut LLVM 11 for 18.04, so it's not recognized in the SHAs in this repository.
It looks like the llvm_release_name script doesn't know that:
https://github.com/grailbio/bazel-toolchain/blob/f2d1ba2c9d713b2aa6e7063f6d11dd3d64aa402a/toolchain/tools/llvm_release_name.py#L96
I think the fix (at least, the point fix) is to patch that line to bump to 20.04 if the LLVM version is >= 11.
(May be a worthwhile larger refactoring to split out that conditional into multiple helpers, e.g. based on distribution?)

I am facing this same issue with ubuntu as well https://github.com/grailbio/bazel-toolchain/blob/master/toolchain/tools/llvm_release_name.py#L89
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
Traceback (most recent call last):
File "/builder/home/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 110, column 37, in llvm_toolchain_impl
_download_llvm_preconfigured(rctx)
File "/builder/home/.cache/bazel/_bazel_root/eab0d61a99b6696edb3d2aff87b585e8/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 190, column 13, in download_llvm_preconfigured
	fail("Unknown LLVM release: %s\nPlease ensure file name is correct." % basename)
Error in fail: Unknown LLVM release: clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz

authors: ankit-scio cceckman

repo: grailbio/bazel-toolchain


text:
updating wiki article content on website separately from CLDF full rendering

Hi @xrotwang
As was discussed before, we want to push changes in grambank/grambank.wiki to the clld website separately from the full cldf rendering. We talked about this before. Is this going to be possible?
We're currently aiming at 13th of December as final date for all the wiki reviews to be finished.
In the meantime we've noticed some unfortunate things with the rendering of the content on some of the features as website content

Links to general wiki articles don’t always work (e.g. ‘boundness’ in GB114)
Tables don’t always render (e.g. GB026)
‘and’ in “Jay and Jeremy” has funny quotation marks

What can we do to help with this?

AFAIR what we discussed was including newer versions of the wiki into the CLDF data based on older versions of the data repository. And yes, that's possible. The website is always fed from a CLDF dataset which includes data and descriptions.
Regarding rendering problems: I'll have a look. Exact descriptions of the problems would be good, though. E.g. I cannot find a problem on https://grambank.clld.org/parameters/GB114 - in fact, I can't even find the word "boundness" on the page at all.

The table in GB026 seems to have been replaced in the meantime, see https://github.com/grambank/grambank/wiki/GB026

Okay, good. @alenawitzlack @tobiaskweber and @jlesg were the ones noticing discrepancies so I'll let them write more here if there's more to note.

The funny quotation marks are gone in the code (see https://github.com/clld/grambank/commit/3018a467a228b6b4f6250c32f692e002e847c17b#diff-81a3f3b4e2f5047ea03031a9d59779087ad1b5d2b14c21503365ae4632d52ce6) but the change hasn't been deployed yet.

Going through the articles on the website now may not be super helpful, considering there's still editing going on in the wiki. Better would be a review period after December 13 and after the latest changes have been pushed to the website.

We are reviewing the articles based on the wiki page, we're just looking at the way things are rendered on the website in general. The way tables are made in the wiki articles shouldn't change much after the 13th for example, so the same issues should remain I believe.

That's at least my understanding, that @jlesg and the others were raising more general notes with specific examples.

Hey @xrotwang and @HedvigS ,
Thank you for taking the time for bringing this up and discussing this.
One of the things we discussed during the meeting was that we're not entirely sure which problems are

because of an earlier version of the wiki articles on GitHub, and
which problems may have to do with the push to the website.

I'd like to have a brief look at the website articles next week. Possibly most issues are due to 1), so they may no longer be issues.
I'll come back with some exact descriptions of problems later, if they're still around!
All the best,
Jakob

I haven't been able to have a good look at these yet.
Let's hold off the push to the website until we have agreed that the wiki is fairly final, some point after the 13th. Like @xrotwang said. It's possible that not everything will be finished by the 13th. Some patrons have had unusually busy schedules the last few weeks.

@xrotwang just letting you know we're at the last stage of finalising wiki now, I'll let you know when it's ready for things to happen in this regard.
The patrons are currently making smaller changes to the feature question wording, which I believe means we also need to update the "gb20.txt" document which the CLDF rendering uses. What is the easiest way of making that link?

Info that can be read from the wiki is taken from there. So no need to sync respective fields in gb20.txt.

Okay, great.
For the CLDF "parameters.csv" and the way the Feature "Name" is rendered there, that is taken from gb20.txt right?

Yes. Could be replaced with the wiki title, though.

authors: HedvigS jlesg xrotwang

repo: grambank/grambank


text:
Grammy.dev 502 API reference

First of all thank you a lot for this tool!
There's a problem with the deployed website, you might already know about.
If you go to grammy.dev and click API Reference - the link to https://doc.deno.land/https://deno.land/x/grammy/mod.ts
will be broken and show you 502 - DEPLOYMENT_FAILED.
I'm not sure if it's on your end or Deno deploy. Yet, that would be nice to look into.
Thank you!

That was probably a temporary issue. Please try again, it works for me.

That was probably a temporary issue. Please try again, it works for me.

Indeed! It might be something wrong with deno.doc.land then, it's been pretty sluggish lately.
Thank you.

authors: KnorpelSenf vinclou

repo: grammyjs/grammY

license: MIT


text:
Use 🌏 for Chinese

#649 had to be adjusted to #596 but wasn't. This PQ fixes that.

No conventional commits please thanks OK

why not

(but ok)

why not

because

:(

repo: grammyjs/website


text:
No way to return an error once the WebSocket connection is established

There is no way to return an error once a connection is established.
func (r *Resolver) OnMessage(ctx context.Context, args struct {
	ChatID string
}) (chan *MessageResolver, error) {
	ch := make(chan *MessageResolver)
	msgCh, errCh := r.Service.Subscribe(args.ChatID)
	go func() {
		defer close(ch)
		for {
			select{
			case <-ctx.Done():
				return
			case <-errCh:
				// TODO: how to send error back to client
				return
			case msg, ok := <-msgCh:
				if !ok {
					return
				}
				ch <- &MessageResolver{
					Message: msg,
				}
			}
		}
	}()
	return ch, nil
}

@lstrihic can u share full code example to see how can enable and use ws for graphql-go subscription, thank u

Basically the full example is in the description not sure what else you want me to provide. (updated description code a bit)
We need a way to handle the error when I receive it from an errCh.
I hope this helps.

I believe that in such cases you have to include some error message or state inside of your message schema. For example, one of the members of the MessageResolver could be an Err field. And then your code would look like this:
func (r *Resolver) OnMessage(ctx context.Context, args struct {
	ChatID string
}) (chan *MessageResolver, error) {
	ch := make(chan *MessageResolver)
	msgCh, errCh := r.Service.Subscribe(args.ChatID)
	go func() {
		defer close(ch)
		for {
			select{
			case <-ctx.Done():
				return
			case err := <-errCh:
				// TODO: how to send error back to client
				ch <- &MessageResolver{
					Err: err,           // treat errors as part of your data
					Message: nil, // this is redundant, but added for clarity
				}
				return
			case msg, ok := <-msgCh:
				if !ok {
					return
				}
				ch <- &MessageResolver{
					Message: msg,
				}
			}
		}
	}()
	return ch, nil
}

Feel free to reopen if you believe that this is an issue with the library.

Yes, you are right, I can do that, but that is not the way to do it. To me it seems like a walk around solution.
Error should be returned by the library, and it should be structured like this:
{
  "data": {
    "onMessage": null
  },
  "errors": [
    {
      "message": "pubsub is not available",
      "path": [
        "onMessage",
        "error"
      ]
    }
  ]
}

So I wanna be able to somehow tell the library that there is an error and a library should return the error.
Maybe something like graphql.AddError(err).

In that case, feel free to reopen the ticket and I'll look into it. By the way PRs are more than welcome. The resolver would return an error exactly in the format you provided if the error occurred initially. After that it's just messages in this simple implementation.

authors: kamalkech lstrihic pavelnikolov

repo: graph-gophers/graphql-go

license_source: bigquery


text:
SimpleIntEncodedValue can't simply encode an int

I have a variable which is an int and uses the entire range of that type, and I'd like to put it in a SimpleIntEncodedValue. So I create one with 32 bit, which is allowed. But then I can't put in an int because SimpleIntEncodedValue doesn't allow negative values.
In fact, it wastes the 32nd bit because of that. I think that's why this caught me by surprise.

Yes, if we continue to force positive values we could optimize this (or support negative values). The bigger advantage I see in implementing reordering the EncodedValues. E.g. if you have two EVs with 18 bits and two with 10 bits this would require 3 bytes (18 and 18+10 and 10) although with reordering (18+10 and 18+10) only two bytes are required.

(or support negative values)

That, or at least rename the thing. An int is an int, I was very disappointed when I couldn't put my int into the IntEncodedValue. ;-)
UnsignedIntegralEncodedValue or something.

authors: karussell michaz

repo: graphhopper/graphhopper


text:
Carbonlink hashing problem in 1.1.1

Upgraded from 1.0.2 to 1.1.1 yesterday.  Initially things looked good, but the more I dove in, I found metrics missing in-memory values in their graphs.  This looks like the hashing issue I had in 1.0.2 with the fnv1a hash algorithm that made me fall back on the carbon_ch hashing algorithm.
Configs:
# ------------------------------------------------------------------------
# Configure Carbon Query Link
# ------------------------------------------------------------------------
CARBONLINK_HASHING_TYPE = 'carbon_ch'
CARBONLINK_HOSTS = ["127.0.0.1:7102:1", "127.0.0.1:7202:2", "127.0.0.1:7302:3", "127.0.0.1:7402:4", "127.0.0.1:7502:5", "127.0.0.1:7602:6", "127.0.0.1:7702:7", "127.0.0.1:7802:8"]
CARBONLINK_TIMEOUT     = 30.0
CARBONLINK_RETRY_DELAY = 5.0
CARBONLINK_QUERY_BULK  = True

Problem is visible in the graphs with the leading edge missing data for some series and there being dips in graph where aggergaters are being used.

Please use master, there are issues with 1.1.1

Or 1.1.x branch
On Thu, 1 Feb 2018 at 19:30, Dan Cech notifications@github.com wrote:

Please use master, there are issues with 1.1.1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/graphite-project/graphite-web/issues/2220#issuecomment-362358569,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABK51tZr8DgSkXTuJDmOLLPWhgytZT7Kks5tQgK8gaJpZM4R2EWm
.

OK, will rebuild with 1.1.x branch

Do I need both carbon and graphite-web from 1.1.x? I just pulled 1.1.x, rebuilt, and restarted the web server and am still seeing what looks like cache misses, e.g., the graphs look the same (caching is disabled during the test)

You need carbon from 1.1.x to get the fix, graphite-web 1.1.1 or 1.1.x will be fine.

So I just stopped the carbon 1.1.1 daemon, and it exited immediately.. all the in-memory statistics were lost, is that what you mean be "issues" ?

Yes

Have half the cluster running on the new 1.1.x branch.. it's a slow process because I need to stop the carbon-c-relay in front of the caches since they flush correctly and then wait for the carbon 1.1.1 daemons to flush their metrics to disk before I restart the daemons.
It's encouraging so far and I'll have a report later when I have the whole cluster upgraded.

authors: DanCech deniszh reyjrar

repo: graphite-project/graphite-web


text:
Graph-Node on Main Net never completes the sync process

Do you want to request a feature or report a bug?

It might be a bug (not sure)

What is the current behavior?

The graph-node starts the sync process but never finishes it. It is always 1 block behind.
Logs:

Dec 02 18:24:26.136 INFO Graph Node version: 0.19.2 (2020-10-20)
Dec 02 18:24:26.152 INFO Starting up
Dec 02 18:24:26.152 INFO Trying IPFS node at: http://localhost:5001/
Dec 02 18:24:26.159 INFO Creating transport, capabilities: archive, trace, url: http://mainnet.infura.io/v3/[PROJECT_ID], network: mainnet
Dec 02 18:24:26.164 INFO Successfully connected to IPFS node at: http://localhost:5001/
Dec 02 18:24:26.213 INFO Connecting to Postgres, conn_pool_size: 10, url: postgresql://postgres:HIDDEN_PASSWORD@localhost/graph-node
Dec 02 18:24:26.338 INFO Connected to Postgres, url: postgresql://postgres:HIDDEN_PASSWORD@localhost/graph-node, pool_name: main, component: Store
Dec 02 18:24:26.338 DEBG Cleaning up large notifications after about 300s, channel: chain_head_updates, component: ChainHeadUpdateListener > NotificationListener
Dec 02 18:24:26.362 DEBG Cleaning up large notifications after about 300s, channel: store_events, component: NotificationListener
Dec 02 18:24:26.386 INFO Connecting to Ethereum..., capabilities: archive, trace, network: mainnet
Dec 02 18:24:26.410 INFO Connected to Ethereum, capabilities: archive, trace, network_version: 1, network: mainnet
Dec 02 18:24:26.419 INFO Waiting for other graph-node instances to finish migrating, component: Store
Dec 02 18:24:26.432 INFO Running migrations, component: Store
Dec 02 18:24:26.441 INFO Migrations finished, component: Store
Dec 02 18:24:26.441 INFO Completed pending Postgres schema migrations, component: Store
Dec 02 18:24:26.442 DEBG Using postgres host order [Main], component: Store
Dec 02 18:24:26.449 INFO Creating LoadManager in disabled mode, component: LoadManager
Dec 02 18:24:26.450 INFO Starting block ingestors
Dec 02 18:24:26.451 INFO Starting block ingestor for network, network_name: mainnet
Dec 02 18:24:26.477 INFO Starting JSON-RPC admin server at: http://localhost:8020, component: JsonRpcServer
Dec 02 18:24:26.489 INFO Starting GraphQL HTTP server at: http://localhost:8000, component: GraphQLServer
Dec 02 18:24:26.490 INFO Resolve subgraph files using IPFS, subgraph_id: QmPo4KMXbqK8SEvpd5FTr6DeQrQoK9qr4iPj87ne9ZuGXx, component: SubgraphAssignmentProvider
Dec 02 18:24:26.490 INFO Resolve manifest, link: /ipfs/QmPo4KMXbqK8SEvpd5FTr6DeQrQoK9qr4iPj87ne9ZuGXx, subgraph_id: QmPo4KMXbqK8SEvpd5FTr6DeQrQoK9qr4iPj87ne9ZuGXx, component: SubgraphAssignmentProvider
Dec 02 18:24:26.491 INFO Starting index node server at: http://localhost:8030, component: IndexNodeServer
Dec 02 18:24:26.492 INFO Starting metrics server at: http://localhost:8040, component: MetricsServer
Dec 02 18:24:26.493 INFO Starting GraphQL WebSocket server at: ws://localhost:8001, component: SubscriptionServer
Dec 02 18:24:26.513 INFO Syncing 2 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 2, blocks_behind: 2, latest_block_head: 11374718, current_block_head: 11374716, network_name: mainnet, component: BlockIngestor
Dec 02 18:24:30.710 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374719, current_block_head: 11374718, network_name: mainnet, component: BlockIngestor
Dec 02 18:24:50.550 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374720, current_block_head: 11374719, network_name: mainnet, component: BlockIngestor
Dec 02 18:25:26.490 DEBG Trying again after object.stat timed out (attempt #1), subgraph_id: QmPo4KMXbqK8SEvpd5FTr6DeQrQoK9qr4iPj87ne9ZuGXx, component: SubgraphAssignmentProvider
Dec 02 18:26:21.670 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374721, current_block_head: 11374720, network_name: mainnet, component: BlockIngestor
Dec 02 18:26:26.494 DEBG Trying again after object.stat timed out (attempt #2), subgraph_id: QmPo4KMXbqK8SEvpd5FTr6DeQrQoK9qr4iPj87ne9ZuGXx, component: SubgraphAssignmentProvider
Dec 02 18:26:32.003 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374722, current_block_head: 11374721, network_name: mainnet, component: BlockIngestor
Dec 02 18:26:34.601 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374723, current_block_head: 11374722, network_name: mainnet, component: BlockIngestor
Dec 02 18:26:43.667 INFO Syncing 1 blocks from Ethereum., code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 11374724, current_block_head: 11374723, network_name: mainnet, component: BlockIngestor

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

Starting a graph-node container with the following configurations:

- name: node_id
  value: "default"
- name: node_role
  value: "combined-node" # query+index
- name: "ethereum"
  value: "mainnet:http://mainnet.infura.io/v3/[PROJECT_ID]"
- name: "ETHEREUM_POLLING_INTERVAL"
  value: "200"
- name: "ipfs"
  value: "http://localhost:5001"
- name: RUST_LOG
  value: "info"
- name: GRAPH_LOG
  value: "debug"
- name: postgres_host
  value: "localhost"
- name: postgres_user
  value: "postgres"
- name: postgres_db
  value: "graph-node"
- name: postgres_pass
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password
- name: postgres_url
  value: postgres://postgres:$(postgres_pass)@localhost:5432/graph

Even if I use a smaller ETHEREUM_POLLING_INTERVAL it does not sync with mainnet.

What is the expected behavior?

If the sync does not complete, the graph-node is not ready to respond to requests. So the ideal would be to have it synced and ready to start accepting requests.

Hi we're not aware of any bug that would cause this, could it be that somehow your network connection is slow? In what environment are you running this?

I see the same issue when spinning up a new graph node, it looks like it ingests only new blocks. And when I try to deploy a subgraph I get subgraph validation error: [the specified block must exist on the Ethereum network].  Any suggestions?

authors: DSalko fforbeck leoyvens

repo: graphprotocol/graph-node


text:
Track subgraph processing status

In addition to having a block pointer, each subgraph could have a "status" indicator. This would have a few benefits. First, we don't currently have a way to detect whether a subgraph has hit an unrecoverable error, other than by looking at the logs or noticing that the subgraph block pointer has stopped updating.
It would be helpful if a subgraph could enter an "error" state in which processing is halted, which would then be reflected in UIs, monitoring systems, etc.
Second, I'm thinking of tracking whether a subgraph's processing has reached the chain head block at least once. This isn't needed for correctness, but it's helpful from a monitoring perspective to understand why a particular subgraph is far behind the chain head. If a subgraph has just been deployed and it is far behind the chain head, that is a normal situation, but if a subgraph that has already caught up to the chain head once is now many blocks behind, that could indicate a performance problem with the node or an unusual situation with the subgraph.

closed as dupe


text:
Failed to deploy graph node - "Invalid operation type error. at line 59 column 3"

I was able to deploy this subgraph initially, but now I'm unable to deploy new versions. I can run graph codegen and graph build without any issues.
Here's the output of running graph deploy --studio juicebox
The error at the end isn't giving me enough information to debug.
I'm using graph-cli version 0.21.0, node v16.5.0, running on a Mac M1
✔ Version Label (e.g. v0.0.1) · 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.1 to 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.2 to 0.0.3
  Skip migration: Bump mapping apiVersion from 0.0.3 to 0.0.4
  Skip migration: Bump mapping specVersion from 0.0.1 to 0.0.2
✔ Apply migrations
✔ Load subgraph from subgraph.yaml
  Compile data source: Projects => build/Projects/Projects.wasm
  Compile data source: TerminalV1 => build/Projects/Projects.wasm (already compiled)
✔ Compile subgraph
  Copy schema file build/schema.graphql
  Write subgraph file build/Projects/abis/Projects.json
  Write subgraph file build/TerminalV1/abis/TerminalV1.json
  Write subgraph manifest build/subgraph.yaml
✔ Write compiled subgraph to build/
  Add file to IPFS build/schema.graphql
                .. Qmd9z2gQh9negCbgJvjcQHEnv12cLUs5PNawWkiLeUxyu4
  Add file to IPFS build/Projects/abis/Projects.json
                .. QmcQ6Jazax2Zs7nS5yiatJfBruLbnDgPh1Z6s8Ymo2R9Bn
  Add file to IPFS build/TerminalV1/abis/TerminalV1.json
                .. Qma83sCmBYhEETWk1FnicgxpVuXFV9ffY6PKzHcVTdDtMX
  Add file to IPFS build/Projects/Projects.wasm
                .. QmbEFthRpcD9A9ZcySbZe9Q2BBZhDSEtzZVUdFbH4QFBhr
  Add file to IPFS build/Projects/Projects.wasm
                .. QmbEFthRpcD9A9ZcySbZe9Q2BBZhDSEtzZVUdFbH4QFBhr (already uploaded)
✔ Upload subgraph to IPFS

Build completed: QmVKSTRM8E693ZVXtBVMmbN32nmTKKx8SkDdwfe1cwSkNV

✖ Failed to deploy to Graph node https://api.studio.thegraph.com/deploy/: subgraph resolve error: resolve error: Serialization error: Invalid operation type error. at line 59 column 3

Are you using solidity 8? I think you have maybe encountered this error https://github.com/graphprotocol/graph-node/issues/2577

I just hit this error, it seems to come from Solidity 0.8.4 errors.
These errors appear in the ABI file like this:
  { "inputs": [], "name": "MustBeOwner", "type": "error" },

It seems that the graph-cli needs to add support for parsing these errors.

@azf20 I am using solidity 8.6, looks like that's exactly what I've been blocked on
@dmihal have you found a workaround yet, like trying to strip customErrors from the abi before using it to compile a subgraph? theoretically that would still be usable no?

Update: I tried deploying this subgraph with the errors removed from the ABI and it failed syncing. I'm guessing this is because of the ABI mismatch https://thegraph.com/studio/subgraph/juicebox/

@dmihal yes - the parsing is actually required on the graph-node side (it is there that the ABI is being parsed, and rejected)
@peripheralist yes that is the correct fix - I don't think there is a reason syncing would fail because of the ABI mismatch, so I expect that something else went wrong. If you can share the deployment hash we could take a look.

Thanks, is this the deployment hash? QmQoZzZCjuAym1Wy31hehErn5HfHwDKAXbEGuRLkv3X78g

Yes it looks like that has failed for another reason:
failed to process trigger: block #12834007 (0x5c38…57b1), transaction c815a8587a49d7379322be6ce69f6c5d7c1995cb3754d01a96ecd549793d6d36: Entity PayEvent[0xc815a8587a49d7379322be6ce69f6c5d7c1995cb3754d01a96ecd549793d6d36-115]: missing value for non-nullable field `memo`\twasm backtrace:\t    0: 0x13ea - <unknown>!generated/schema/PayEvent#save\t    1: 0x1447 - <unknown>!src/mapping/handlePay\t

thanks @azf20 , seems like that's saying an empty value was passed for memo. in that case an error would be thrown, except that i removed the errors from the abi... which is probably causing this to fail? do you have any ideas for a workaround?
also, is there somewhere i could find those logs so i don't have to bug you for them?

@peripheralist the removed errors in the ABI are not related to this subgraph failure (they are thrown on an error in the EVM execution, not the subgraph execution).
it looks like you have a non-nullable field in your schema, and you are trying to save a null value. You can query for these kinds of errors per here

@azf20 yes! didn't understand the non-null GraphQL type before, but i'm clear on it now. syncing succeeded. thanks for the help!
for anyone else coming here using solidity 8, just confirming that you can still deploy your subgraph by manually removing the errors from your ABI 👍

You can query for these kinds of errors per here

@azf20 i'm trying to follow the instructions in that link, but it seems like this is for the legacy explorer—i'm using studio. what should i be using for subgraphName, and where is the deployment hash relevant?

hi @peripheralist apologies yes those docs apply to the legacy explorer, you should be able to run
  indexingStatuses(subgraphs: ["QmQoZzZCjuAym1Wy31hehErn5HfHwDKAXbEGuRLkv3X78g"]) {
    synced
    health
    fatalError {
      message
      block { number }
      handler
    }
    subgraph
    chains {
      chainHeadBlock {
        number
      }
      latestBlock {
        number
      }
    }
  }
}```
on the same endpoint.
Conscious that this discussion has moved off the topic of this issue, please [join our Discord](https://discord.gg/vtvv7FP) and use #subgraph-development for ongoing discussion

Errors are now supported, closing this, thanks!

authors: azf20 dmihal peripheralist

repo: graphprotocol/graph-tooling


text:
Error for array of address field.

With Array of address field graph-cli generate field as [Bytes] which fails while codegen.
On fixing [Bytes] to [Bytes!] in conversion file we are getting error below error as array of bytes cannot be directly assigned to array of address.
ERROR TS2322: Type '~lib/array/Array<~lib/@graphprotocol/graph-ts/common/numbers/Address>' is not assignable to type '~lib/array/Array<~lib/@graphprotocol/graph-ts/common/collections/Bytes>'.

Suggestion:
As we don't have support directly from thegraph for address type attributes (We get validation error), we need to generate code which will loop-over the array fields.

Hi! Can you provide a bit more detail on when you see this error - is this coming from auto-generated graph codegen code? Do you have a test case or example where you are seeing this error?

I've just run into this issue, it's fairly easy to reproduce. Just have a contract with an event, with one of it's args being a address[]. This causes graph init to generate the following Graphql code:
...
owners: [Bytes]! # address[]
...

Graphql doesn't seem to like this:
GraphQL schema can't have List's with Nullable members.
Error in 'owners' field of type '[Bytes]'.
Suggestion: add an '!' to the member type of the List, change from '[Bytes]' to '[Bytes!]'

The solution, as suggested by the error message, is to change that line to:
owners: [Bytes!]! # address[]

The problem with this is that, since this fails during the graph init command, now I don't know if that did all it needed to do, or if there were some steps skipped because of the error. The fix should just be to generate the correct Graphql types.

Well, the change mentioned above only fixes codegen. When you try to build the subgraph it fails. The line that fails is the one trying to map the address[] from the event to the entity: entity.owners = event.params.owners.
The error is the same from this other issue: https://github.com/graphprotocol/graph-cli/issues/1017
I've tried to rewrite that line in different ways, but nothing seems to fully work. These two options also crash the assemblyscript compiler for some reason:
entity.owners = event.params.owners.map((x) => x);

entity.owners = [];
  event.params.owners.forEach((x) => {
    const bytes = x as Bytes;
    const copy = Bytes.fromHexString(bytes.toHexString());
    entity.owners.push(copy);
  });

And then this variant builds and deploys, but then, querying the GraphQL API doesn't return data for the owners property, again, not sure why:
  // entity.owners = new Array(event.params.owners.length);
  entity.owners = [];
  for (let i = 0; i < event.params.owners.length; i++) {
    // entity.owners[i] = event.params.owners[i];
    // if (event.params.owners[i]) {
    entity.owners.push(event.params.owners[i]);
    // }
  }

I suppose address[] is just not working now, and that's a blocker for me at the moment :(

I have also tried to do exactly what CLI told
after changing the owners: [Bytes]! # address[] to owners: [Bytes!]! # address[] the graph codegen command worked compeletly fine but
when I run the build command it shows me the error that I mentioned in my issue #1017
and i have did some digging and changed the type in ts file which is used for build
entity.targets = changetype<Bytes[]>(event.params.targets)
here the event.params.targets is an Address[] and entity.targets is a Bytes[]
so i have changed it's type with changetype<Bytes[]>.
i don't know if this is a good fix or not but it worked.

Contract 0xe1844c5D63a9543023008D332Bd3d2e6f1FE1043
Network: Japan Open Chain
ERROR TS2322: Type 'Array<Address>' is not assignable to type 'Array<Bytes>'.

   entity.requiredDVNs = event.params.requiredDVNs
                         ~~~~~~~~~~~~~~~~~~~~~~~~~
 in src/send-uln-302.ts(32,25)

authors: YaroShkvorets azf20 pablote realchoubey sdakhara


text:
Using property/getter macros for GraphQL::Field

I can use methods with the @[GraphQL::Field] annotation, but using the property, or getter macros seems to fail.
It would be nice if we could do this
@[GraphQL::Field]
property id : String?

vs
@[GraphQL::Field]
def id : String?
  @id
end

This comes in handy when you have a JSON::Serializable object

This is blocked by https://github.com/crystal-lang/crystal/issues/7504
class Query
  @[GraphQL::Field]
  property id : String?

  macro finished
    {% for ivar in @type.instance_vars %}
      pp {{ ivar.annotation(GraphQL::Field).stringify }}
    {% end %}
  end
end
// => Nothing

Not sure if there is a workaround.

It works with JSON::Serializable/JSON::Field. Surely there must be a way to make it work. 🤔
https://github.com/crystal-lang/crystal/blob/master/src/json/serialization.cr#L161-L177

Interesting, accessing instance_vars inside methods does work, but not inside finished. I believe finished is required, although I don't remember what the reason was. But I am getting weird errors when I try to remove them.
If anyone can show me how to remove finished from the current code I'd be happy add this.

Good news, I found a way. Apparently there's a difference between macro expressions in methods (which have instance_vars available) and macros that define methods (which do not).

authors: Qard jgillich jwoertink

repo: graphql-crystal/graphql


text:
Upgrade to spring-boot 2.7.1 fails

Describe the bug
After updating project to spring boot version 2.7.1. Application fails on startup.
To Reproduce
Steps to reproduce the behavior:

Update pom to 2.7.1
Add de dependencies

        <groupId>com.graphql-java-kickstart</groupId>

        <artifactId>graphql-spring-boot-starter</artifactId>

        <version>12.0.0</version>

    </dependency>

    <dependency>

        <groupId>com.graphql-java-kickstart</groupId>

        <artifactId>graphql-spring-boot-starter-test</artifactId>

         <version>12.0.0</version>

        <scope>test</scope>

    </dependency>

See error
{"@timestamp":"2022-06-30 19:30:50.234","@version":"1","message":"Error starting Tomcat context. Exception: org.springframework.beans.factory.UnsatisfiedDependencyException. Message: Error creating bean with name 'graphQLServletRegistrationBean' defined in class path resource [graphql/kickstart/autoconfigure/web/servlet/GraphQLWebAutoConfiguration.class]: Unsatisfied dependency expressed through method 'graphQLServletRegistrationBean' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'graphQLHttpServlet' defined in class path resource [graphql/kickstart/autoconfigure/web/servlet/GraphQLWebAutoConfiguration.class]: Unsatisfied dependency expressed through method 'graphQLHttpServlet' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'graphQLServletConfiguration' defined in class path resource [graphql/kickstart/autoconfigure/web/servlet/GraphQLWebAutoConfiguration.class]: Unsatisfied dependency expressed through method 'graphQLServletConfiguration' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'invocationInputFactory' defined in class path resource [graphql/kickstart/autoconfigure/web/servlet/GraphQLWebAutoConfiguration.class]: Unsatisfied dependency expressed through method 'invocationInputFactory' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'graphQLSchemaProvider' defined in class path resource [graphql/kickstart/autoconfigure/web/servlet/GraphQLWebAutoConfiguration.class]: Unsatisfied dependency expressed through method 'graphQLSchemaProvider' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'graphQLSchema' defined in class path resource [graphql/kickstart/autoconfigure/tools/GraphQLJavaToolsAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [graphql.schema.GraphQLSchema]: Factory method 'graphQLSchema' threw exception; nested exception is java.lang.NoSuchMethodError: 'graphql.schema.GraphQLDirective graphql.schema.idl.SchemaGeneratorHelper.buildAppliedDirective(graphql.schema.idl.SchemaGeneratorHelper$BuildContext, graphql.language.Directive, java.util.Set, graphql.introspection.Introspection$DirectiveLocation, graphql.schema.GraphqlTypeComparatorRegistry)'","logger":"org.springframework.boot.web.embedded.tomcat.TomcatStarter","thread":"main","level":"ERROR","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.270","@version":"1","message":"Stopping service [Tomcat]","logger":"org.apache.catalina.core.StandardService","thread":"main","level":"INFO","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.274","@version":"1","message":"The web application [ROOT] appears to have started a thread named [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:\n java.base@15/java.lang.Object.wait(Native Method)\n app//oracle.jdbc.driver.BlockSource$ThreadedCachingBlockSource$BlockReleaser.run(BlockSource.java:331)","logger":"org.apache.catalina.loader.WebappClassLoaderBase","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.275","@version":"1","message":"The web application [ROOT] appears to have started a thread named [InterruptTimer] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:\n java.base@15/java.lang.Object.wait(Native Method)\n java.base@15/java.util.TimerThread.mainLoop(Timer.java:553)\n java.base@15/java.util.TimerThread.run(Timer.java:506)","logger":"org.apache.catalina.loader.WebappClassLoaderBase","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.276","@version":"1","message":"The web application [ROOT] appears to have started a thread named [AppPool housekeeper] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:\n java.base@15/jdk.internal.misc.Unsafe.park(Native Method)\n java.base@15/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)\n java.base@15/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661)\n java.base@15/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)\n java.base@15/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)\n java.base@15/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)\n java.base@15/java.lang.Thread.run(Thread.java:832)","logger":"org.apache.catalina.loader.WebappClassLoaderBase","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.277","@version":"1","message":"The web application [ROOT] appears to have started a thread named [AppPool connection adder] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:\n java.base@15/jdk.internal.misc.Unsafe.park(Native Method)\n java.base@15/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)\n java.base@15/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661)\n java.base@15/java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:460)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1055)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)\n java.base@15/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)\n java.base@15/java.lang.Thread.run(Thread.java:832)","logger":"org.apache.catalina.loader.WebappClassLoaderBase","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.278","@version":"1","message":"The web application [ROOT] appears to have started a thread named [LiquibasePool housekeeper] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:\n java.base@15/jdk.internal.misc.Unsafe.park(Native Method)\n java.base@15/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)\n java.base@15/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1661)\n java.base@15/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)\n java.base@15/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)\n java.base@15/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)\n java.base@15/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)\n java.base@15/java.lang.Thread.run(Thread.java:832)","logger":"org.apache.catalina.loader.WebappClassLoaderBase","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.279","@version":"1","message":"Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start web server; nested exception is org.springframework.boot.web.server.WebServerException: Unable to start embedded Tomcat","logger":"org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext","thread":"main","level":"WARN","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.282","@version":"1","message":"AppPool - Shutdown initiated...","logger":"com.zaxxer.hikari.HikariDataSource","thread":"main","level":"INFO","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.433","@version":"1","message":"AppPool - Shutdown completed.","logger":"com.zaxxer.hikari.HikariDataSource","thread":"main","level":"INFO","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.433","@version":"1","message":"LiquibasePool - Shutdown initiated...","logger":"com.zaxxer.hikari.HikariDataSource","thread":"main","level":"INFO","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.445","@version":"1","message":"LiquibasePool - Shutdown completed.","logger":"com.zaxxer.hikari.HikariDataSource","thread":"main","level":"INFO","application":"service-demo"}
{"@timestamp":"2022-06-30 19:30:50.498","@version":"1","message":"\r\n\r\n***************************\r\nAPPLICATION FAILED TO START\r\n***************************\r\n\r\nDescription:\r\n\r\nAn attempt was made to call a method that does not exist. The attempt was made from the following location:\r\n\r\n    graphql.schema.idl.SchemaGeneratorHelperExt.buildAppliedDirective(SchemaGeneratorHelperExt.kt:19)\r\n\r\nThe following method did not exist:\r\n\r\n    'graphql.schema.GraphQLDirective graphql.schema.idl.SchemaGeneratorHelper.buildAppliedDirective(graphql.schema.idl.SchemaGeneratorHelper$BuildContext, graphql.language.Directive, java.util.Set, graphql.introspection.Introspection$DirectiveLocation, graphql.schema.GraphqlTypeComparatorRegistry)'\r\n\r\nThe calling method's class, graphql.schema.idl.SchemaGeneratorHelperExt, was loaded from the following location:\r\n\r\n    jar:file:/D:/dev/maven-repo/com/graphql-java-kickstart/graphql-java-tools/11.1.2/graphql-java-tools-11.1.2.jar!/graphql/schema/idl/SchemaGeneratorHelperExt.class\r\n\r\nThe called method's class, graphql.schema.idl.SchemaGeneratorHelper, is available from the following locations:\r\n\r\n    jar:file:/D:/dev/maven-repo/com/graphql-java/graphql-java/18.1/graphql-java-18.1.jar!/graphql/schema/idl/SchemaGeneratorHelper.class\r\n\r\nThe called method's class hierarchy was loaded from the following locations:\r\n\r\n    graphql.schema.idl.SchemaGeneratorHelper: file:/D:/dev/maven-repo/com/graphql-java/graphql-java/18.1/graphql-java-18.1.jar\r\n\r\n\r\nAction:\r\n\r\nCorrect the classpath of your application so that it contains compatible versions of the classes graphql.schema.idl.SchemaGeneratorHelperExt and graphql.schema.idl.SchemaGeneratorHelper\r\n","logger":"org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter","thread":"main","level":"ERROR","application":"service-demo"}
Expected behavior
Normal startup
Desktop (please complete the following information):

OS: [Windows]
Browser [Not Applicable, application fails on startup]
Version [12.0.0]

Ok, I believe the issue is in the extended-validation library.
Behavior:
Graphql queries containing directives like @connection, @NotBlank etc, cause the above behavior. If removed the application starts up normaly.
I will create an issue by graphql-java-extended-validation team.


text:
fix: remove statement pending discussion

I made the choice of adding this to the readme w/o consulting colleauges
My co-maintainers are being forced to take sides and this is unfair
The technical steering commitee will review this decision, & decide what best reflects our interests together.
First and foremost, they will decide on a policy to make sure a rouge maintainer action like this cannot happen again without a decision making process involving the TSC.
I apologize for making this choice but not what I said, and will continue supporting an end to the apartheid in my own personal venues.
Please leave my co-maintainers and colleauges be.

Can you free Tibet instead?

repo: graphql/graphiql


text:
massage charts

Fixes a bug and refactors a few things.

Set to WIP. Sounds like @seanlinsley wants to push more commits here.

The charts JS has now been heavily refactored, so before merging please be sure to test it.

!m @seanlinsley

license: mit


text:
[CI] Add new release note step for release

Issue
https://gravitee.atlassian.net/browse/APIM-367
Description
The goal is to remove the use of GitHub milestones
This step open a PR into https://github.com/gravitee-io/gravitee-docs with empty Release Notes template to be completed.
And try to add some info to help to complete the Release Notes in PR body like commit list and link to Jira filtered to "Done" issues of this release
Pr linked : https://github.com/gravitee-io/gravitee-docs/pull/912
Additional context
Pr example : https://github.com/gravitee-io/gravitee-docs/pull/910
📝 BackPorted on each supported version when(if) this PR are ✅

🚀 CI was able to deploy the build of this PR, so you can now try it directly here
Notes: The deployed app is linked to the management API of APIM master. (Same login and password as APIM master)

📚  View the storybook of this branch here

Why is there a submodule created ?

Why is there a submodule created ?
oups to remove

repo: gravitee-io/gravitee-api-management


text:
Problem with chart (Analytics/Monitoring)

The Chart is not displayed on Analytics/Monitoring with Gravitee 0.6.0 / Elasticsearch version : 1.7.4
There is no error on elasticsearch, the cluster is ok.
Here you can find the error on gravitee.log.
[gravitee-listener-30] ERROR i.g.m.s.impl.AnalyticsServiceImpl - An unexpected error occurs while searching for analytics data.
java.lang.NullPointerException: null
at io.gravitee.repository.elasticsearch.analytics.ElasticAnalyticsRepository.toHistogramResponse(ElasticAnalyticsRepository.java:222) ~[gravitee-repository-elasticsearch-0.5.0.jar:na]
at io.gravitee.repository.elasticsearch.analytics.ElasticAnalyticsRepository.hitsByApi(ElasticAnalyticsRepository.java:163) ~[gravitee-repository-elasticsearch-0.5.0.jar:na]
at io.gravitee.repository.elasticsearch.analytics.ElasticAnalyticsRepository.query(ElasticAnalyticsRepository.java:76) ~[gravitee-repository-elasticsearch-0.5.0.jar:na]
at io.gravitee.management.service.impl.AnalyticsServiceImpl.runHistoricalQuery(AnalyticsServiceImpl.java:136) [gravitee-management-api-service-0.6.0.jar:na]
at io.gravitee.management.service.impl.AnalyticsServiceImpl.apiHits(AnalyticsServiceImpl.java:122) [gravitee-management-api-service-0.6.0.jar:na]
at io.gravitee.management.service.impl.AnalyticsServiceImpl.apiHitsByStatus(AnalyticsServiceImpl.java:56) [gravitee-management-api-service-0.6.0.jar:na]
at io.gravitee.management.rest.resource.ApiAnalyticsResource.hits(ApiAnalyticsResource.java:79) [gravitee-management-api-rest-0.6.0.jar:na]
at sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source) ~[na:na]

This issue seems to be due when you are working with a fresh installation of Elasticsearch without any data.


text:
Update graxEmbedded.js-meta.xml

Added targetConfig for LightningCommunity (Experience Cloud)

niice! did some reading but still not sure what to look for here 😅 where can I check the result of this?
is this related to #19?

This is related to #19 . I have this code loaded in a sandbox if you would like to look at it there @pedro. Let me know and I will get you access to it to test this out.

cool! talked in Slack and tested this fine 👌
leaving for Noah given it's a PR on his changes

thanks, pulling this in and testing myself!

authors: blewis-grax nzoschke pedro

repo: graxinc/grax-salesforce-embedded


text:
Show health of harvesters

It is important to know if there are issues with the harvesters or all the plotting was for nothing.
Add a button to check Health of harvesters.
Show a text based summary and a Heatmap of lookup times per Harvester, as slow lookup times can make you miss out on a reward if you have the solution but your harvester cannot deliver in time.

Most basic stats are in the current release. More coming

TODO

[ ] Selectbox for summary time.
Current commit summarizes the last 500 entries (about 90 minutes).
Selectbox for 56 (10m), 333 (60min), 500 (90m), 1500 (3h), 7000 (12h), 8000 (day), 10080 (week), all

[ ] Tab for each harvester
Sub-tab showing heatmap over lookup time
Sub-tab listing last n entries

[ ] Refresh harvester dialog
SummaryTime <= 60min refresh every minute
SummaryTime > 60min refresh every ten minutes

[ ] Caching mechanism for harvester logs.
Don't reread debug.log2, debug.log3, etc if they did not change.
Don't use TailLineEmitter to stay updated: it keeps the log file open and could prevent chias log rotation.
Persist cache of debug.log2 and the others and clean up/update the cache when log rotation happend

repo: grayfallstown/Chia-Plot-Status


text:
[ASK] Node Port

Did The Port Is Set Default To :8333?
Are There Anyway To Change This BTW?

The port is the correct default whether you use mainnet or testnet.
You can change it by editing the config like you would normally do on bitcoin core (bitcoin.conf configuration) - there is an embedded [poor] editor within the app

authors: Firdausfarul greenaddress

repo: greenaddress/abcore


text:
Bump documentation link to the 4.3.7 series

It would be nice if we had a /current/ or /latest/ URL rewrite for the documentation so we don't have to maintain this link manually but until then let's make it point at the most recent version.

Since there were no objections, pushed this to master.


text:
specify git workflow

@jrawbits requested we use an agreed upon git workflow. He suggested reviewing this tutorial as well.

This is now specified here Development-Guidelines

repo: gregorbj/VisionEval


text:
Add xsltproc to the Docker file

Re issue #2
Untested, edited in github. Did install xsltproc and docbook-xsl in my local docker and it then builds fine

thanks!

authors: alanz gregwebs

repo: gregwebs/ghc-docker-dev


text:
GeekOpsUA та Дизайн спільноти у фб

GeekOpsUA:
_https://discord.gg/jNwNr7g97F_
Чат про DevOps, знижки на курси, сертифікацію та пошуки роботи.
Contributor's Checklist:

[x] I have read and understood the contribution rules. My submission complies with these rules.
[x] My submission is grammatically correct.
[X] My submission follows the general Awesome List guidelines. You can check it running the Awesome Lint locally. We also run linter on CI.

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Hello, @grem11n
Could you, please, take a look?
Thanks.


text:
Update update_home_assistant_configuration.md

Inconsistencies detected by Issue:
https://github.com/grimmpp/home-assistant-eltako/issues/38
ID and temperature_unit were missing for the current version.

Hello @LHBL2003,
thanks for the PR. I don't really see what changed and because of what reason? Can you please explain it to me?

Line 129 was missing: - id: 1
This shifted everything by two spaces.
The missing ID led to the issue I had created. https://github.com/grimmpp/home-assistant-eltako/issues/38
Line 121 / 128: temperature_unit: °C
This was my first error before the ID, which I was able to fix by deleting the lines for Climate. Since I wanted to document the missing ID for you, I also had to investigate this error. The error was that the temperature_unit line seemed to be a required field.

DE:
Zeile 129 fehlte: - id: 1
Dadurch wurde alles um zwei Leerzeichen verschoben.
Das Fehlen der ID führte zu dem Issue, das ich erstellt hatte. https://github.com/grimmpp/home-assistant-eltako/issues/38
Zeile 121 / 128: temperature_unit: °C
Dies war mein erster Fehler vor der ID, den ich beheben konnte, indem ich die Zeilen für Climate löschte. Da ich für dich das Fehlen der ID Dokumentieren wollte musste ich diesen Fehler auch nachgehen. Der Fehler bestand darin, dass die Zeile temperature_unit ein Pflichtfeld zu sein schien.

repo: grimmpp/home-assistant-eltako


text:
npm run build error: ERROR  failed to build renderer process

 / building renderer process

   ERROR  failed to build renderer process

    Hash: 4fc364bbd0870352c32f
    Version: webpack 4.46.0
    Time: 19867ms
    Built at: 2021/04/25 下午3:43:28
                              Asset       Size  Chunks             Chunk Names
              imgs/logo--assets.png    211 KiB          [emitted]
                         index.html  294 bytes          [emitted]
                        renderer.js   1.91 MiB       0  [emitted]  renderer
             static/css/animate.css   75.9 KiB          [emitted]
           static/css/bulma.min.css    172 KiB          [emitted]
     static/css/bulmaswatch.min.css    215 KiB          [emitted]
    static/css/font-awesome.min.css   30.3 KiB          [emitted]
            static/grin_mw_logo.png   22.9 KiB          [emitted]
            static/grin_mw_logo.svg   2.12 KiB          [emitted]
    Entrypoint renderer = renderer.js
      [0] ./node_modules/moment/moment.js 170 KiB {0} [built]
      [1] external "path" 42 bytes {0} [built]
      [2] external "fs" 42 bytes {0} [built]
      [3] external "child_process" 42 bytes {0} [built]
      [4] external "electron" 42 bytes {0} [built]
      [5] ./node_modules/axios/index.js 40 bytes {0} [built]
      [7] ./node_modules/vue-style-loader/lib/addStylesClient.js + 1 modules 6.71 KiB {0} [built]
          | ./node_modules/vue-style-loader/lib/addStylesClient.js 6.09 KiB [built]
          | ./node_modules/vue-style-loader/lib/listToStyles.js 637 bytes [built]
     [14] external "vue-i18n" 42 bytes {0} [built]
    [220] ./node_modules/bulma/css/bulma.css 477 bytes {0} [built]
    [222] ./node_modules/animate.css/animate.css 473 bytes {0} [built]
    [224] ./node_modules/bulma-pageloader/dist/css/bulma-pageloader.min.css 498 bytes {0} [built]
    [228] external "vue-electron" 42 bytes {0} [built]
    [229] external "vue-moment" 42 bytes {0} [built]
    [230] external "vue-truncate-filter" 42 bytes {0} [built]
    [231] ./src/renderer/main.js + 1678 modules 1.87 MiB {0} [built]
          | ./src/renderer/main.js 2.56 KiB [built]
          | ./node_modules/vue/dist/vue.esm.js 319 KiB [built]
          | ./src/renderer/messagebus.js 58 bytes [built]
          | ./src/shared/config.js 6.45 KiB [built]
          | ./src/shared/logger.js 647 bytes [built]
          | ./src/shared/walletv3.js 9.28 KiB [built]
          | ./src/shared/gnode.js 4.78 KiB [built]
          | ./src/renderer/db.js 2.27 KiB [built]
          | ./src/shared/tor.js 2.77 KiB [built]
          | ./src/shared/wallet.js 16.2 KiB [built]
          | ./src/renderer/App.vue 510 bytes [built]
          | ./node_modules/vue-awesome/components/Icon.vue 445 bytes [built]
          | ./node_modules/vue-awesome/icons/index.js 36.2 KiB [built]
          | ./src/lang/en.js 13.6 KiB [built]
          | ./src/lang/zh.js 12.7 KiB [built]
          |     + 1664 hidden modules
        + 217 hidden modules

    ERROR in Template execution failed: ReferenceError: process is not defined

    ERROR in   ReferenceError: process is not defined

      - index.ejs:102
        /data/work/niffler/src/index.ejs:102:2

      - index.ejs:107 module.exports
        /data/work/niffler/src/index.ejs:107:3

      - index.js:284
        [niffler]/[html-webpack-plugin]/index.js:284:18

    Child html-webpack-plugin for "index.html":
             Asset     Size  Chunks  Chunk Names
        index.html  537 KiB       0
        Entrypoint undefined = index.html
        [0] ./node_modules/html-webpack-plugin/lib/loader.js!./src/index.ejs 1.39 KiB {0} [built]
        [1] ./node_modules/lodash/lodash.js 531 KiB {0} [built]
        [2] (webpack)/buildin/module.js 497 bytes {0} [built]

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! Niffler@0.7.1 build: `node .electron-vue/build.js && electron-builder`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the Niffler@0.7.1 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

use node v11.15.0
see the .nvmrc

authors: xiaojay youngqqcn

repo: grinfans/Niffler


text:
[Feature Request]: organized page by folder

it would be help to give a folder to manger page.
I think it could help when pages increase more and more

@tendertree, this is actually already possible, just a bit differently, see https://support.getgrist.com/page-widgets/#pages:

The trick to creating this nesting is to hold one page over another when dragging -- that makes a nested group. The only difference with your suggestion is that the "folder" is itself a page.

authors: dsagal tendertree

repo: gristlabs/grist-core


text:
Update search_snipe_asset to handle no asset found

Added an if/else statement in search_snipe_asset to check for total to handle the response if no asset is found

We tested this internally, and it solved our issue.

This looks awesome, thank you!

authors: dstocking snipe tanyayeu


text:
Implement new GUI

Update GUI based on Bootstrap SB Admin

First beta available in development branch.


text:
Why is there a maxSession parameter in the hub configuration?

I don't believe that hubs use maxSession, do they? Why does it get put into the default config?
https://github.com/groupon/Selenium-Grid-Extras/blob/e4975cedc265100f36ffb492e4db3a6a1a3413bb/SeleniumGridExtras/src/main/java/com/groupon/seleniumgridextras/config/GridHub.java#L161

I think the hub does have a maxSession parameter. If you just start the jar:
java -jar selenium-server-standalone-2.53.0.jar -role hub
You see this as the config:
http://localhost:4444/grid/console?config=true&configDebug=true
Config for the hub :
host : null
port : 4444
cleanUpCycle : 5000
timeout : 300000
browserTimeout : 0
newSessionWaitTimeout : -1
grid1Mapping : {}
throwOnCapabilityNotPresent : true
capabilityMatcher : org.openqa.grid.internal.utils.DefaultCapabilityMatcher
prioritizer : null
servlets :
all params :
browserTimeout : 0
capabilityMatcher : org.openqa.grid.internal.utils.DefaultCapabilityMatcher
cleanUpCycle : 5000
host : null
jettyMaxThreads : -1
maxSession : 5
newSessionWaitTimeout : -1
nodePolling : 5000
port : 4444
prioritizer : null
role : hub
servlets : []
throwOnCapabilityNotPresent : true
timeout : 300000

@JustinTulloss If this answer is sufficient, please close this issue. Thank you.

I still don't believe that the option actually does anything, but it sounds like it's a selenium hub problem not a grid extras problem. Also I don't really care :)

authors: JustinTulloss smccarthy

repo: groupon/Selenium-Grid-Extras