[8.9] Gradle build daemon crashes immediately (in low-memory environment?)

Current Behavior
An automated PR that upgrades gradle to latest stable version fails the build with

Full message
Downloading https://services.gradle.org/distributions/gradle-8.9-bin.zip
............10%.............20%.............30%.............40%.............50%.............60%.............70%.............80%.............90%.............100%

Welcome to Gradle 8.9!

Here are the highlights of this release:
 - Enhanced Error and Warning Messages
 - IDE Integration Improvements
 - Daemon JVM Information

For more details see https://docs.gradle.org/8.9/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
Will push to remote build cache
> Task :plugins:lintKotlinMain
> Task :plugins:lintKotlinTest NO-SOURCE
> Task :plugins:validateEditorConfigForKtlint FROM-CACHE
> Task :plugins:lintKotlin
> Task :plugins:checkKotlinGradlePluginConfigurationErrors SKIPPED
> Task :plugins:pluginDescriptors
> Task :plugins:processResources
> Task :plugins:processTestResources NO-SOURCE
> Task :plugins:compileKotlin

The message received from the daemon indicates that the daemon has disappeared.
Build request sent: Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>}
Attempting to read last messages from the daemon log...
Daemon pid: 365
  log file: /home/runner/.gradle/daemon/8.9/daemon-365.out.log
----- Last  20 lines from daemon log file - daemon-365.out.log -----
2024-07-18T07:52:15.988+0000 [DEBUG] [org.gradle.launcher.daemon.server.DefaultDaemonConnection] thread 30: Received non-IO message from client: Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>}
2024-07-18T07:52:15.988+0000 [INFO] [org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler] Received command: Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>}.
2024-07-18T07:52:15.989+0000 [DEBUG] [org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler] Starting executing command: Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>} with connection: socket connection from /<IP_ADDRESS>:39117 to /<IP_ADDRESS>:50946.
2024-07-18T07:52:15.992+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Command execution: started DaemonCommandExecution[command = Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>}, connection = DefaultDaemonConnection: socket connection from /<IP_ADDRESS>:39117 to /<IP_ADDRESS>:50946] after 0.0034166666666666664 minutes of idle
2024-07-18T07:52:15.992+0000 [INFO] [org.gradle.launcher.daemon.server.DaemonRegistryUpdater] Marking the daemon as busy, address: [42650d56-1b7e-4677-ae19-3f5ffc61d89f port:39117, addresses:[localhost/<IP_ADDRESS>]]
2024-07-18T07:52:15.992+0000 [DEBUG] [org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Marking busy by address: [42650d56-1b7e-4677-ae19-3f5ffc61d89f port:39117, addresses:[localhost/<IP_ADDRESS>]]
2024-07-18T07:52:15.993+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on daemon addresses registry.
2024-07-18T07:52:15.993+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-07-18T07:52:15.995+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2024-07-18T07:52:15.995+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] resetting idle timer
2024-07-18T07:52:15.995+0000 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] daemon is running. Sleeping until state changes.
2024-07-18T07:52:15.996+0000 [INFO] [org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy] Daemon is about to start building Build{id=7c0c0075-8025-4128-b766-512b5ee3e257, currentDir=/home/runner/_work/<REDACTED>}. Dispatching build started information...
2024-07-18T07:52:15.997+0000 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 32: dispatching org.gradle.launcher.daemon.protocol.BuildStarted@336744c2
2024-07-18T07:52:15.999+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Configuring env variables: [PATH, <REDACTED>]
2024-07-18T07:52:16.006+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.LogToClient] About to start relaying all logs to the client via the connection.
2024-07-18T07:52:16.006+0000 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] The client will now receive all logging from the daemon (pid: 365). The daemon log file: /home/runner/.gradle/daemon/8.9/daemon-365.out.log
2024-07-18T07:52:16.009+0000 [INFO] [org.gradle.launcher.daemon.server.exec.LogAndCheckHealth] Starting build in new daemon [memory: 494.9 MiB]
2024-07-18T07:52:16.012+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has started executing the build.
2024-07-18T07:52:16.012+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=5e5f4e20-65ec-47b9-8ed6-f8ba456ec6b2,javaHome=/home/runner/_work/_tool/Java_Temurin-Hotspot_jdk/21.0.4-7.0.LTS/x64,javaVersion=21,daemonRegistryDir=/home/runner/.gradle/daemon,pid=365,idleTimeout=10800000,priority=NORMAL,applyInstrumentationAgent=true,nativeServicesMode=ENABLED,daemonOpts=--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=384m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]
Will push to remote build cache----- End of the daemon log -----

FAILURE: Build failed with an exception.

* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

Running with info reveals more info

--info output
Resolve mutations for :plugins:processTestResources (Thread[#138,Execution worker Thread 8,5,main]) started.
:plugins:processTestResources (Thread[#138,Execution worker Thread 8,5,main]) started.
Skipping task ':plugins:processTestResources' as it has no source files and no previous output files.
i: starting the daemon as: /home/runner/_work/_tool/Java_Temurin-Hotspot_jdk/21.0.4-7.0.LTS/x64/bin/java -cp /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/2.0.0/1de310de3446414381282ffc46c3ed3919a4d1da/kotlin-compiler-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/2.0.0/b48df2c4aede9586cc931ead433bc02d6fd7879e/kotlin-stdlib-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/2.0.0/fdc27dd047d592fa41d2dfa21e7621287a361612/kotlin-script-runtime-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.6.10/1cbe9c92c12a94eea200d23c2bbaedaf3daf5132/kotlin-reflect-1.6.10.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-daemon-embeddable/2.0.0/b39c612768614c4428c96ee9c65477181fffe9d/kotlin-daemon-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.intellij.deps/trove4j/1.0.20200330/3afb14d5f9ceb459d724e907a21145e8ff394f02/trove4j-1.0.20200330.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar -Djava.awt.headless=true -Djava.rmi.server.hostname=<IP_ADDRESS> -Xmx512m -XX:MaxMetaspaceSize=384m -XX:ReservedCodeCacheSize=320m -Dkotlin.environment.keepalive -ea -XX:+UseCodeCacheFlushing -XX:+UseParallelGC --add-exports java.base/sun.nio.ch=ALL-UNNAMED org.jetbrains.kotlin.daemon.KotlinCompileDaemon --daemon-runFilesPath /home/runner/.kotlin/daemon --daemon-autoshutdownIdleSeconds=7200 --daemon-compilerClasspath /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/2.0.0/1de310de3446414381282ffc46c3ed3919a4d1da/kotlin-compiler-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/2.0.0/b48df2c4aede9586cc931ead433bc02d6fd7879e/kotlin-stdlib-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/2.0.0/fdc27dd047d592fa41d2dfa21e7621287a361612/kotlin-script-runtime-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.6.10/1cbe9c92c12a94eea200d23c2bbaedaf3daf5132/kotlin-reflect-1.6.10.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-daemon-embeddable/2.0.0/b39c612768614c4428c96ee9c65477181fffe9d/kotlin-daemon-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.intellij.deps/trove4j/1.0.20200330/3afb14d5f9ceb459d724e907a21145e8ff394f02/trove4j-1.0.20200330.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar
i: #1 retrying connecting to the daemon
Options for KOTLIN DAEMON: IncrementalCompilationOptions(super=CompilationOptions(compilerMode=INCREMENTAL_COMPILER, targetPlatform=JVM, reportCategories=[0, 3], reportSeverity=2, requestedCompilationResults=[0], kotlinScriptExtensions=[]), areFileChangesKnown=false, modifiedFiles=null, deletedFiles=null, classpathChanges=NotAvailableForNonIncrementalRun, workingDir=/home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/cacheable, multiModuleICSettings=MultiModuleICSettings(buildHistoryFile=/home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/local-state/build-history.bin, useModuleDetection=false), usePreciseJavaTracking=true, icFeatures=IncrementalCompilationFeatures(withAbiSnapshot=false, preciseCompilationResultsBackup=true, keepIncrementalCompilationCachesInMemory=true, enableUnsafeIncrementalCompilationForMultiplatform=false), outputFiles=[/home/runner/_work/<REDACTED>/plugins/build/classes/kotlin/main, /home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/cacheable, /home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/local-state])----- End of the daemon log -----

FAILURE: Build failed with an exception.

* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

* Try:
> Run with --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

the build failure exception is:
* Exception is:
org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
	at org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:282)
	at org.gradle.launcher.daemon.client.DaemonClient.monitorBuild(DaemonClient.java:255)
	at org.gradle.launcher.daemon.client.DaemonClient.executeBuild(DaemonClient.java:208)
	at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:172)
	at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:97)
	at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:56)
	at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:167)
	at org.gradle.launcher.cli.DefaultCommandLineActionFactory$ParseAndBuildAction.execute(DefaultCommandLineActionFactory.java:333)
	at org.gradle.launcher.cli.DefaultCommandLineActionFactory$ParseAndBuildAction.execute(DefaultCommandLineActionFactory.java:297)
	at org.gradle.launcher.cli.DebugLoggerWarningAction.execute(DebugLoggerWarningAction.java:74)
	at org.gradle.launcher.cli.DebugLoggerWarningAction.execute(DebugLoggerWarningAction.java:30)
	at org.gradle.launcher.cli.WelcomeMessageAction.execute(WelcomeMessageAction.java:96)
	at org.gradle.launcher.cli.WelcomeMessageAction.execute(WelcomeMessageAction.java:40)
	at org.gradle.launcher.cli.NativeServicesInitializingAction.execute(NativeServicesInitializingAction.java:50)
	at org.gradle.launcher.cli.NativeServicesInitializingAction.execute(NativeServicesInitializingAction.java:27)
	at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:41)
	at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:26)
	at org.gradle.launcher.cli.DefaultCommandLineActionFactory$WithLogging.execute(DefaultCommandLineActionFactory.java:445)
	at org.gradle.launcher.Main.doAction(Main.java:35)
	at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:52)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
	at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
	at org.gradle.launcher.GradleMain.main(GradleMain.java:31)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.gradle.wrapper.GradleWrapperMain.main(SourceFile:70)

Expected Behavior
The daemon doesn't crash
Context (optional)

I'm not able to reproduce the issue locally
The issue happens only on self-hosted github runners
Our infra provides multiple sizes of runners, and from my testing the issue seems to happen only on the following setup:

750MB of memory (I see the config has "187" of "cpu", but I'm not sure what it means)
1.5GB of memory (I see the config has "375m" of "cpu")

The smallest runner that doesn't reproduce the issue has 3GB of RAM (and has "750m" of "cpu")
I scanned through 8.9's release notes, but I can't see anything related to increased RAM requirements or expected changed to the daemon 👀
The project I'm testing on is tiny (just a small set of private gradle plugins), that's why it was assigned to such a small runner (with just 750MB of ram)
Everything works fine in 8.8 and did in all other 8.x and probably 7.x too
Running with --no-daemon makes the build pass

Steps to Reproduce
I can't provide repro project :/ It doesn't seem to be a project specific issue, but rather an environment one
Gradle version
8.9
Gradle version that used to work
8.8
Build scan URL (optional)
The build scan is not available :/
Your Environment (optional)
No response

Thank you for reporting the issue
We will try to investigate the issue with the provided information. However, it would be helpful if you could provide the project causing the issue (or an equivalent project). The memory dumps for the corresponding Gradle versions could be also helpful.
Can you confirm that running with --no-daemon actually runs without a daemon as opposed to spawning a single-use daemon?
Related documentation: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

Any chance you can try with an 8.10 nightly?
There have been some attempts at improving memory recently. And maybe the line crossing you seem to experience is already resolved.

when running with --no-daemon I see the follwing message the logs:

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.9/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build

so I guess the build uses single-use daemon

The memory dumps for the corresponding Gradle versions could be also helpful.

Can you point me at should I do that? I know how to pass jvmArgs to tasks to automatically dump the memory on OOM exception, but I'm not sure how to do a memory dump before(?) the daemon crashes 👀

Any chance you can try with an 8.10 nightly?

I tested 8.10-20240718001640+0000 and I observe the same behavior

--info output
Resolve mutations for :plugins:processResources (Thread[#140,Execution worker Thread 11,5,main]) started.
:plugins:processResources (Thread[#140,Execution worker Thread 11,5,main]) started.
Caching disabled for task ':plugins:processResources' because:
  Not worth caching
Task ':plugins:processResources' is not up-to-date because:
  No history is available.
file or directory '/home/runner/_work/<REDACTED>/plugins/src/main/resources', not found
Resolve mutations for :plugins:processTestResources (Thread[#140,Execution worker Thread 11,5,main]) started.
:plugins:processTestResources (Thread[#140,Execution worker Thread 11,5,main]) started.
Skipping task ':plugins:processTestResources' as it has no source files and no previous output files.
i: starting the daemon as: /home/runner/_work/_tool/Java_Temurin-Hotspot_jdk/21.0.4-7.0.LTS/x64/bin/java -cp /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/2.0.0/1de310de3446414381282ffc46c3ed3919a4d1da/kotlin-compiler-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/2.0.0/b48df2c4aede9586cc931ead433bc02d6fd7879e/kotlin-stdlib-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-script-runtime/2.0.0/fdc27dd047d592fa41d2dfa21e7621287a361612/kotlin-script-runtime-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.6.10/1cbe9c92c12a94eea200d23c2bbaedaf3daf5132/kotlin-reflect-1.6.10.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-daemon-embeddable/2.0.0/b39c612768614c4428c96ee9c65477181fffe9d/kotlin-daemon-embeddable-2.0.0.jar:/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.intellij.deps/tr
i: #1 retrying connecting to the daemon
Options for KOTLIN DAEMON: IncrementalCompilationOptions(super=CompilationOptions(compilerMode=INCREMENTAL_COMPILER, targetPlatform=JVM, reportCategories=[0, 3], reportSeverity=2, requestedCompilationResults=[0], kotlinScriptExtensions=[]), areFileChangesKnown=false, modifiedFiles=null, deletedFiles=null, classpathChanges=NotAvailableForNonIncrementalRun, workingDir=/home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/cacheable, multiModuleICSettings=MultiModuleICSettings(buildHistoryFile=/home/runner/_work/<REDACTED>/plugins/build/kotlin/compileKotlin/local-state/build-history.bin, useModuleDetection=false), usePreciseJavaTracking=true, icFeatures=IncrementalCompilationFeatures(withAbiSnapshot=false, preciseCompilationResultsBackup=true, keepIncrementalCompilationCachesInMemory=true, enableUnsafeIncrementalCompilationForMultiplatform=false), outputFiles=[/home/runner/_work/<REDACTED>/plugins/b
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
* Try:
> Run with --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
* Exception is:
org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
(...)

To get a heap dump you could try adding.
org.gradle.jvmargs=-Xmx<YourMemorySettings>m -XX:+HeapDumpOnOutOfMemoryError

On crash you might then find java_pid.hprof file in working dir.

When trying to come up with a reproducer, I initially assumed it's enough to have an environment with low amount of available RAM, but I couldn't reproduce the issue with only that 👀
The more code I remove the later the daemon dies (Initially it started during compileKotlin now I'm at validatePlugins which is the last task to run, I think.
The current exception is:
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :plugins:lintKotlinMain
> Task :plugins:lintKotlinTest NO-SOURCE
> Task :plugins:validateEditorConfigForKtlint
> Task :plugins:lintKotlin
> Task :plugins:checkKotlinGradlePluginConfigurationErrors SKIPPED
> Task :plugins:pluginDescriptors
> Task :plugins:processResources
> Task :plugins:processTestResources NO-SOURCE
> Task :plugins:compileKotlin
> Task :plugins:compileJava NO-SOURCE
> Task :plugins:classes
> Task :plugins:compileTestKotlin NO-SOURCE
> Task :plugins:compileTestJava NO-SOURCE
> Task :plugins:pluginUnderTestMetadata
> Task :plugins:testClasses UP-TO-DATE
> Task :plugins:test NO-SOURCE
> Task :plugins:validatePlugins
> Task :plugins:validatePlugins FAILED

7 actionable tasks: 7 executed
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':plugins:validatePlugins'.
> There was a failure while executing work items
   > A failure occurred while executing org.gradle.plugin.devel.tasks.internal.ValidateAction
      > Failed to run Gradle Worker Daemon
         > Unable to connect to the child process 'Gradle Worker Daemon 2'.
           It is likely that the child process have crashed - please find the stack trace in the build log.
           This exception might occur when the build machine is extremely loaded.
           The connection attempt hit a timeout after 1[20](https://github.com/<REDACTED>/actions/runs/9994153725/job/27623257177#step:5:21).0 seconds (last known process state: STARTED, running: true).

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 3m 44s

I tried adding a org.gradle.jvmargs=-XX:+HeapDumpOnOutOfMemoryError, but the memory has not been dumped (from my observation the daemon doesn't crash because of OOM) 🤷
Here's a repro I'm able to reproduce the issue on: https://github.com/mateuszkwiecinski/gradle_daemon_doesnt_work (smallest I can publicly share, not smallest that reproduces the issue, sorry :/. It can probably be stripped even further).
I'll also mention how I ended up with such repro:

After I removed ~all of the code - the build passed
I restored some of the code - the build failed
I removed all dependencies (because they weren't used) - the build passed
I restored some of the dependencies - the build started to fail again
I removed buildscript dependency on ktlint wrapper - the build started passing
I kept the buildscript dependency removed and restored dependencies and all the code (suspecting that's the root cause) the build started to fail (with the same exception) again.

The failure is fully reproducible, and goes away when using larger runners (so it will pass on github hosted ubuntu-latest)
And at the end I'll confirm, the same repro, works perfectly fine with Gradle 8.8

On what machine does it fail? Also what happens if you somewhat limit the memory, e.g. you set org.gradle.jvmargs=-Xmx512m?

On what machine does it fail exactly?

Unfortunately I don't know the details, I only see some of its user-facing configuration. I know we use runner sets and that docker image with ubuntu2204-x64 is involved. The following nodes are made available to us (I can switch between them by updating runs-on label on GA):

memory=750Mi, cpu=187m - the daemon crashes here
memory=1.5Gi, cpu 375m - the daemon crashes here
memory=3Gi, cpu=750m - the build passes

I don't know what these memory/cpu settings are translated into specifically :/
I haven't tried larger self-hosted machines. I know it passes on github-hosted ubuntu-latest and it also works fine on self-hosted ARM-based mac runner

Also what happens if you somewhat limit the memory, e.g. you set org.gradle.jvmargs=-Xmx512m?

The daemon still crashes (only on gradle 8.9). And I see the setting reflected in daemon crash log:
Before:
2024-07-18T16:17:28.617+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=7ccbc409-7fed-4cfc-bd38-f874f258c61a,javaHome=/home/runner/_work/_tool/Java_Temurin-Hotspot_jdk/21.0.4-7.0.LTS/x64,javaVersion=21,daemonRegistryDir=/home/runner/.gradle/daemon,pid=292,idleTimeout=10800000,priority=NORMAL,applyInstrumentationAgent=true,nativeServicesMode=ENABLED,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]

After:
2024-07-19T09:36:48.392+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=6c28bab5-75dc-409a-9200-40a59a92491a,javaHome=/home/runner/_work/_tool/Java_Temurin-Hotspot_jdk/21.0.4-7.0.LTS/x64,javaVersion=21,daemonRegistryDir=/home/runner/.gradle/daemon,pid=298,idleTimeout=10800000,priority=NORMAL,applyInstrumentationAgent=true,nativeServicesMode=ENABLED,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,--add-opens=java.base/java.util=ALL-UNNAMED,--add-opens=java.base/java.lang=ALL-UNNAMED,--add-opens=java.base/java.lang.invoke=ALL-UNNAMED,--add-opens=java.prefs/java.util.prefs=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED,--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED,--add-opens=java.base/java.nio.charset=ALL-UNNAMED,--add-opens=java.base/java.net=ALL-UNNAMED,--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]

We got some reports from users that they see more memory consumption for newer Gradle versions (8.9+), it could be 10% compared to 8.5.
We are investigating if that is expected or something needs improvement.

FYI: I spent a small amount of time investigating the issue, and with low heap, e.g. -Xmx256m (or less) it is reproducible for me, but only on first run, i.e. with clean cache. After cache was populated there was no more problem.


Data Prepper Build & Release Process

Summary
The Data Prepper maintainers would like to produce Data Prepper releases more often and reduce the friction with releasing them.
The approach to this goal will be to provide two CI/CD jobs.

Data Prepper Build
Data Prepper Promotion/Release

The first job can run either as a GitHub Action or as part of the OpenSearch build infrastructure. The second job must be part of the OpenSearch build infrastructure since it relies on signing and upload keys.
Data Prepper Artifacts
Data Prepper must produce the following artifacts as part of the release process.

Data Prepper Docker image on DockerHub
Linux archive distribution (.tar.gz) via opensearch.org
Java libraries on Maven Central

In the future Data Prepper may include other platform distributions such as macOS or Windows. That is beyond the current scope however.
Data Prepper Build
The Data Prepper Build job will be maintained and run by the Data Prepper maintainers. It will produce artifacts into repositories which are owned by the Data Prepper maintainers.
The Data Prepper maintainers will own two repositories:

An S3 bucket for .tar.gz and Maven artifacts.
An AWS ECR repository for Docker images

The job will have the following steps:

Output Directory Structure
The following is an example directory structure for the artifacts.
/
  1.3.0/
    {buildNumber}/
      distribution/
        opensearch-data-prepper-1.3.0-linux-x64.tar.gz
        opensearch-data-prepper-jdk-1.3.0-linux-x64.tar.gz
      maven/
        data-prepper-api/
          maven-metadata-local.xml
          1.3.0-SNAPSHOT/
            data-prepper-api-1.3.0-SNAPSHOT-javadoc.jar
            data-prepper-api-1.3.0-SNAPSHOT.jar
            data-prepper-api-1.3.0-SNAPSHOT.pom
            data-prepper-api-1.3.0-SNAPSHOT-sources.jar
            data-prepper-api-1.3.0-SNAPSHOT.module
            maven-metadata-local.xml

Data Prepper Promotion/Release
The Promotion/Release job will be part of the OpenSearch infrastructure. It will download the artifacts from the Build. It then signs them and uploads them to the final OpenSearch distribution repositories.
This job must be parameterized. It will take the following parameters:

versionNumber - The version number to promote
sourceBuildNumber - The build number of the source job which produced the artifacts for promotion

The job can be visualized as having the following steps:

This job will be a Jenkins job running on the OpenSearch infrastructure. The Data Prepper maintainers will be the primary authors, but collaborate with the OpenSearch infrastructure maintainers on the job.
Manual Steps: I believe that currently there is a manual step to migrate from the Sonatype staging repository into Maven Central. If this is not necessary, then this job can be updated accordingly.
Tasks

[ ] Investigate GitHub Actions for the primary job
[ ] Confirm approach with OpenSearch infrastructure maintainers
[ ] Setup necessary infrastructure; in particular the ECS repository
[ ] Create Data Prepper build job
[ ] Update Data Prepper promotion job in OpenSearch build
[ ] Remove old Data Prepper build job from OpenSearch build

Lets work together on some parts of this, I'm using data-prepper for our POC https://github.com/opensearch-project/opensearch-build/issues/1539

Here is a proof of concept for the new release model using data prepper, we should review this together and see how we can fill some of the design gaps between our systems https://github.com/peternied/data-prepper/pull/1/files


add openapi-gen=true for some structs

Since we want to create openapi spec for Kubeflow KFServing that depends on knative, but no "+k8s:openapi-gen=true" comments in the knative structs so that the openapi-gen will not load the knative structs.
The PR is going to add "// +k8s:openapi-gen=true" comments for some knative structs. Thanks.

/ok-to-test

/hold

/hold cancel

/lgtm
/approve


Please help - can not open code in demo as solution or project

Hi @gmhevinci
I just download and import RPG as Unity Project, Then I unzip MotionFramework folder.
But when I double click to the code file (.cs file), my Rider application can not recognize it as a solution.
I try MotionFramework then it works as a solution, Please see the image I attach for the detail of 2 projects:

Today, I resolve it by adding
"com.unity.ide.rider": "1.2.1",
to the manifest.json in Packages Folder


form-control class added to dropdown toggle button

In the original bs-select library I noticed that the form-control class is not applied to the generated dropdown toggle button. It is left in the outer div only.

    <button type="button" class="btn dropdown-toggle btn-default" data-toggle="dropdown" title="Select CFU" aria-expanded="false">

Using this library, if the form-control class is applied to the  element it is automatically applied also to the dropdown toggle button. I found the code for this here:
if(className === 'form-control') {
       dropdownToggle.addClass(className);
}

Can you explain why?
In my project this causes me issues, since it overrides the background of the toggle button. But I guess you had a good reason for this choice.

form-control class will give the button width value 100% when you need use nyaBsSelect in an form-horizontal form.
https://github.com/twbs/bootstrap/blob/master/less/forms.less#L116
if you don't need the style of form-control, just don't use this class. it's not mandatory.

I didn't explain myself well. I need the form-control class, but from what I can see it's ok to have it just in the parent element, that in my case is:
<ul class="form-control nya-bs-select" ...
If I comment out the lines that assign the class also to the button, all is working well anyway, since the width 100% is given to the button anyway from the css:
.nya-bs-select .dropdown-toggle {
    width: 100%;
    padding-right: 25px;
}

My only concern here is that the original library, with the bs-select class, is not assigning the form-control class to the button element too.
Sorry if I'm missing something.

I investigate the whole project. Still can't figure out why I add this line of code. But I think you're right the form-control class is not necessary for the dropdown toggle button. And remove this class won't break current example.

Thank you!


Refactor bigquery tests into a separate module

What type of PR is this?
Test Enhancement

What does this PR do / why is it needed ?

Introduce a new module for BiqQuery tests
Add support for SQL query tests against BigQuery and enable them in Github workflows

Which issue(s) this PR fixes:

Fixes #
Other notes for reviewers:
Does this PR introduce a user-facing change?

No

Good to merge!


Add TXT record type to now dns --help

TXT record support was recently added to now.

It's the little things 💕


Desktop support

Hi!  I was looking at using BDK in a cross-platform Flutter app, but there are issues which each major platform:
Linux: https://github.com/LtbLightning/bdk-flutter/pull/93 is ongoing, but testing was an issue for me.  I will need to revisit this
Windows: https://github.com/LtbLightning/bdk-flutter/issues/9 links to issues which have both been solved, so it should be ready to work on, I will have to boot into Windows soon and try it out
mac: ??? I don't see any issues or PRs related to macOS desktop, does anyone have any pointers or guidance for getting it working there as well?

Hi @sneurlax currently BDK-Flutter supports iOS and Android. Desktop and Web support is on the roadmap but not available yet:

Is your App targeting iOS and Android as well? In addition to Desktop platforms?

Issue #92 was for someone developing for iOS and Android on a Windows desktop. Not for developing a Windows App.
Issue #93 is for adding Linux as a platform in addition to iOS and Android as it does not exist right now.
In short iOS and Android app can be developed at the moment, and this development will work for Desktop platforms when Desktop support is added soon(Unless you are targeting a release date within a few weeks for Desktop).
Happy to discuss further and support with your development.

Thank you for the clarification!  I have recently been working on adding Linux and Windows desktop support for native Flutter plugins which use C++ or Rust wrapped in Dart for cross-platform Flutter apps, so I was looking at adding platform support
but it's not needed right away
when it is, though, if platform support hasn't been added at that time, wouldn't we just need to fork bdk-flutter, add the platforms, build locally, and use our fork repo as a package source until support's merged in?

@sneurlax bdk-flutter will have Desktop support soon. Someone has already attempted this but not successful yet.
You can find more details here: https://github.com/LtbLightning/bdk-flutter/pull/93

@sneurlax bdk-flutter will have Desktop support soon. Someone has already attempted this but not successful yet. You can find more details here: #93

Thanks!  Do you have any leads on adding mac platform support?
We are looking at solidifying Linux, Mac, and Windows platform support for bdk, so any tips or tricks on the process would be very helpful.  Is the process

fork bdk-flutter, add the platforms, build locally, and use our fork repo as a package source until support's merged in?

Waiting for desktop support too.

See:

Linux: https://github.com/LtbLightning/bdk-flutter/issues/107
macOS: https://github.com/LtbLightning/bdk-flutter/issues/105
Windows: https://github.com/LtbLightning/bdk-flutter/issues/106


Problem with binary data

I am reading from a database in which a column is of type "varbinary(max)".
The table is used as input to a CPython module, and I'm getting the following error:
 output_model Binary : There was a data type error: the data type of java.lang.String object [value2] does not correspond to value meta [Binary]

I don't have Lazy conversion enabled

The database is an MS SQL Server?
And are you using the CPython step as the first step (or as in input step), are you using Python to read directly from the database? Or are you using a Table Input step to read the table and then hopping the Table Input step to the CPython step?

The database was MS SQL Server and I was using Cpython to read from the Database and writing to it.
I got around this problem simply by saving a hex string in the database instead.


Poetry lock giving runtime error

I am trying to setup this solution in Cloud shell. When I run poetry lock it give
RuntimeError
The Poetry configuration is invalid:

Additional properties are not allowed (u'group' was unexpected)

The issue is with the Cloud Shell pip install poetry command installs the peotry compatible to 2.7 Python i.e. poetry 1.1.15.
Poetry 1.1.15 doesn't work with group dependencies and also the resolution requires an upgraded version of Poetry (as latest as possible)
Work around you can use

Add the python3 site packages folder to the beginning of the PATH. This will force the system to look for Python3 packages only (e.g. export PATH="/home/admin_/.local/lib/python3.10/site-packages/poetry/bin:$PATH")
Instead of pip install use pip3 install poetry to install poetry in the site python3 folder
Uninstall poetry if already installed using pip so that only Python3 compatible poetry is present

NOTE: This workaround is strictly for cloud shell or for the cases where there is a conflicting/multiple Python Versions installed


https://alexa-node-red.bm.hardill.me.uk down?

nginx / AMI error page shows.
https://alexa-node-red.eu-gb.mybluemix.net is up.
Which is right today btw - are they working in parallel?

The system is all up and running again as of 20mins ago. All working correctly

https://alexa-node-red.bm.hardill.me.uk is correct and up and running
The old bluemix site has not been used in well over a year and as IBM cancelled by login when I left I can't shut it down.

If it's still linked to anywhere in the docs let me known and I'll remove it


tmp

see https://github.com/ipfs/ipfs-desktop/issues/2206

It works. see https://github.com/ipfs/ipfs-desktop/runs/7413210401?check_suite_focus=true and image:


ci: disable broken code coverage on windows

The Code Coverage (windows-latest, windows, nightly-x86_64-pc-windows-gnu) CI step seems to always fail for all PRs, and has been broken for several months now: #6534.
Instead of wasting even more CPU time (and perhaps money?) on a broken CI step that apparently noone wants to fix it, let's just deactivate it for now. If someone wants to fix it later, a FIXME points at the open issue #6686, which also serves as a good place to discuss potential fixes, should someone ever be interested.

As a casual contributor, I second this move. First, it is frustrating to not get a green checkmark on a correct PR. Second, getting a red mark and seeing this test fail requires investigating to determine whether the PR code is to blame or not.


Ensure errors launching emulators are exposed to the daemon

The original emulator code used printError when an error occurred launching an emulator. This worked fine from the CLI but in the daemon it means the response came back successful and then we got a logMessage with the error. This means editors believed the launch worked (Dart Code ends up sitting around waiting for an emulator to connect) and there was an unrelated error.
This code pushes the printError up to the command so that the daemon error handling code will return the error correctly.

BTW, this was checked in when the tree was red. Please avoid checking anything in when the tree is red except for attempts to fix the tree, because it makes it much harder to detect, and later identify, additional failures introduced while the previous failure was ongoing. If you suspect a flaky result, please re-run the test rather than checking in while red. If that isn't possible, at a minimum please note the situation in the PR when landing it. Thanks!

@Hixie Apologies; I thought the failure was from a devicelab test and I thought (perhaps incorrectly) that they couldn't be restarted so I thought since this PR was otherwise green it'd force another build. I will hold off in future :-)

We can restart devicelab builds. Ping me or @cbracken if you think that needs to be done.
But in general, if a test is flakey, then the way to fix it is to mark it flakey in the manifest, that will make it not mark PRs red. See https://github.com/flutter/flutter/blob/master/dev/devicelab/manifest.yaml.


What port does lens need when in internel cluster.

I install a lens in inner network, all port needed must apply for obviously.
so except for the 6443 port. what other port does lens needs?

Are you trying to install lens into a cluster?
What do you mean by "inner network", do you mean some local corporate network?

no, I want to install lens in my windows-10 personal computer.

Inner network means, k8s intalled in a network environment that all ports closed by default.all ports that needed must be apllied for. so except for 6443, I want to know what other ports should I apply.

Oh so you mean what ports does Lens try and access the kube API on? Whatever port is defined in your kubeconfig I assume since we use kubectl proxy

for example, if I want to "Shell to Pod", then only 6443 is not worked.

for example, if I want to "Shell to Pod", then only 6443 is not worked.


'snapshot_pre' is deprecated, 'backup_pre' should be used instead

21-09-19 03:31:18 WARNING (MainThread) [supervisor.addons.validate] Add-on config 'snapshot_pre' is deprecated, 'backup_pre' should be used instead. Please report this to the maintainer of In-memory MariaDB

Thank you. I'm aware of this:

This is already patched in the original add-on, but not released yet as a new version (https://github.com/home-assistant/addons/commit/5416d080df917c8ec0e8f4a2b6166ad9f3a90a1f).
I already cherry-picked this commit into my upstream merge branch (https://github.com/lmagyar/homeassistant-addon-mariadb-inmemory/commit/2273db244db708b8c9655ceca407f0767bcfc92c).
Now I'm waiting for a new version of the official mariadb add-on to bump my version. I think it is not critical at the moment if they didn't released a new version yet.


Create a README for new Kraken 2 Repo

This functions as a test ticket as well as a task item to create a new README with updated paths and config management.

Adding a comment through zube integration

test comment. planning for release 9/31

First iteration is OK

Need to change front page README.md

Since i will be learning k2 in the next few days, would you guys mind me giving this a go?


Improve notification UX for trusting notebooks

Currently when using notebooks that user VS Code's notebook api, you get prompted every time you open a .ipynb file:

I understand why we cannot run notebook code automatically, but showing the prompt as soon as you open a file feels aggressive. A few thoughts:

Could the warning be shown somewhere else instead of a notification?

Could we defer showing the error until there is content that we know will not be rendered or until the user performs an operation, such as trying to execute a cell?

/cc @rebornix

To answer your questions:

Could the warning be shown somewhere else instead of a notification?

We'd need some other place to put this in the VS code notebook UI. The only place we can stick things is in the toolbar and the output. Kai has mentioned you guys might add the ability for us to have docked panes in the window (we want this to show variables). Might be able to put an untrusted banner at the top then.

Could we defer showing the error until there is content that we know will not be rendered or until the user performs an operation, such as trying to execute a cell?

Any output is considered a security risk. So without an output banner at the top, the user won't know why their old output isn't showing up.

We're not going to make any changes to how we manage trusted notebooks. We're waiting for VS Code to implement trusted workspaces. At that point, this is moot.


Only one action can be dispatched at a time

Hello and thanks for your work here.
I've encountered a limitation of the dispatcher implementation that prevents me from having multiple actions being dispatched at the same time. While I think I do understand the reasons behind this limitation, I'd like to be sure to understand them. Could you enlighten me here please?
Anyway, I changed my code to avoid this but from what I understand from Flux and particularly in the case of various action sources, I will meet them again if I have:

view_actions
server_actions (xhr)
realtime_actions (websocket)

How can I ensure that there will be one and only one action trigger at a given time since I cannot predict when all those actions are sent? I was thinking of making the dispatcher managing a queue but it's not in the official dispatcher implementation (see http://facebook.github.io/flux/docs/dispatcher.html) so I guess I'm missing something.
That's probably something I should ask the React/Flux team though, but you might help me to figure this out.

@jawb Think of the events more as business events that different components can choose how to respond to.. not specific instructions of how to change the view.  In your case you should have a single event defined for whatever is triggering this action.  Your stores and views can react to this event by opening the modal and removing the data (Remember that multiple stores can be listening to the same event)

According to @BinaryMuse and @jsilvestre, two constraints we need to obey to prevent two actions dispatched at the same time,

don't dispatch new action within an action handler;
dispatching loop should be synchronous.

I totally agree with #1, but constraint #2 is so strong that prevent me from applying some design decisions.
Before I read this issue I planned to have my Store doing two optional tasks on receiving an action,

making XHR calls;
persisting store data.

Knowing that dispatching loop should be synchronous, I decided to move XHR calls out of action handler, only after the XHR calls are finished I create an action and make the dispatch call, this is fine since making XHR calls doesn't require much knowledge about the inner structure of Store.
But I am stuck in the data persistent part. I am working with react-native and want to persist data with AsyncStore or through my exposed sqlite module, the persistent works in async way. I can ignore the async callbacks but it leads to inconsistent on failure.
What should be the best practice?

OK I understand, per @BinaryMuse's comment, It's fine to dispatch a new action in async callback, so in my case I can finish the task with two actions: one for triggering data persistent, the other for triggering UI update on data persistent result.


Setup CI using Travis

Attempt to enable continuous integration with Travis CI.

@acreilly  can you help out with any questions here?

It happens that I can test the configuration on my fork: stay tuned


CAMEL-10015: Fix Braintree Syntax

Thanks @apupier :-)
The PR has been merged. Can you close this? :-)


Lab 4, Exercise 2: Error with Get a row by ID

Lab 4: Custom Connectors
Exercise 2: Modify cloud flow to use connector
Task 1: Use custom connector in flow
Step 6: Select Loans for Table name, click on the Row ID field and select LoanID from the dynamic content pane.
Description of issue
Working through the steps as written, the test fails at "Get Loan" (Get a row by ID action).
While debugging, I noticed that the output from the Lookup Loan Number step has a loaned value of " 6f054d95-c4d3-ed11-a7c7-000d3a8fbb5c" (notice the leading space). This leading space causes the flow to fail at the Get Loan step.
Repro steps:

Create the flow as written in the exercise.

Proposed solution:

At step 6, use a Trim expression with loanID, which works like a charm.

Thank you jamarx2. Labs are updated now.


Bug: Root elements order with seed::empty

View code:
fn view(model: &Model) -> impl ElContainer<Msg> {
    // it has to be vec! and in root to reproduce bug
    vec![
        if model.show_first {
            // it works with div![] or span![], etc
            seed::empty()
        } else {
            div!["Something"]
        },
        button![
            "Toggle element",
            simple_ev(Ev::Click, Msg::ToggleElement)
        ]
    ]
}

Expected order after click on button "Toggle element" (It'll set model.show_first to false) :

div "Something"
button "Toggle element"

Actual order:

button "Toggle element"
div "Something"

Whole example: https://github.com/MartinKavik/seed/tree/fix/patch-seed-empty/examples/patch_seed_empty_bug_demo

@David-OConnor I noticed commit Fixed a bug with rendering multiple Els from top level. which can have something common with this bug and there are some todos - I don't want to change code under your hands and I suppose that you'll fix it more effectively than I do.
If you don't have time or there will be other obstacles, just ping me and I'll write tests and I'll try to fix it.

I'll take this one. Likely caused by me improperly testing the latest patch.

Fixed. The problem was the next_node parameter in patch() not being properly passed from rerender_vdom().

Nice! I've tried it in #121.


Add: Functionality to resume-training from a previously stopped run.

This PR will add support for resuming training from a previously stopped run; the epoch is read from the checkpoint if present. However, the recipe must be provided explicitly.
Add --resume argument, and provide a checkpoint with epoch #;
For example:
sparseml.image_classification.train \
--recipe-path zoo:cv/classification/resnet_v1-50/pytorch/sparseml/imagenette/pruned-conservative?recipe_type=original \
--checkpoint-path ~/models/custom-checkpoint/fake-epoch-2.pth \
--pretrained True --dataset imagenette --dataset-path dataset \
--train-batch-size 128 --test-batch-size 256 --loader-num-workers 8 \
--model-tag resnet50-imagenette-pruned-conservative --resume

The checkpoint must contain epoch # when training was stopped, else it is assumed to be epoch 0
{
     "state_dict" : ...,
     "epoch" : 2,
      .
      .
}

@rahul-tuli @bfineran correct me if I am wrong, but shouldn't we be making sure that when resuming, not only do we extract the correct epoch from the checkpoint, but also the correct state of the optimizer (e.g. learning rate, scheduler state), as well as applying checkpoint weights?


Consolidate action logic

Fixes #112.

This will inevitably conflict with #113.

Ready for review.

It's starting to get confusing who has responsibility for the model, since multiple actors are storing and changing it now (e.g., the NotebookCells object sets the active index; many other more complicated things are set in the manager). Maybe the manager can have each of its functions take a model as the first argument (so it really is just a namespace of functions). Or maybe we can clarify what the basic operations of a model are, compared to what you should put in the manager.
As an example of things to consider: basic undo is supported in the manager now. Should that be integrated in the model instead? What if we wanted to replace the model with an immutability.js-based model to implement easy undo/redo - how would something like that work in the current architecture? If such undo/redo support should be in the manager, then should other things be directly changing the model?
This looks good for now, and I think is an important step in the right direction. I'm going to keep thinking about how to more cleanly structure things.


Server/multithreading

🦙 MegaLinter status: ❌ ERROR

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

✅ CPP
clang-format
41
1
0
0.15s

❌ CPP
cpplint
41

2
0.87s

See detailed report in MegaLinter reports
MegaLinter is graciously provided by


Setup

add torch and torchvision requirements

Codecov Report

Merging #64 (1dd29be) into main (c062030) will increase coverage by 32.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##            main      #64       +/-   ##
==========================================
+ Coverage   0.87%   33.02%   +32.15%
==========================================
  Files         28       36        +8
  Lines        459      645      +186
  Branches      18       29       +11
==========================================
+ Hits           4      213      +209
+ Misses       455      426       -29
- Partials       0        6        +6

Impacted Files
Coverage Δ

towhee/dag/utils.py
0.00% <0.00%> (ø)

towhee/array/array.py
0.00% <0.00%> (ø)

towhee/engine/task.py
0.00% <0.00%> (ø)

towhee/engine/engine.py
0.00% <0.00%> (ø)

towhee/engine/pipeline.py
0.00% <0.00%> (ø)

towhee/engine/variable.py
0.00% <0.00%> (ø)

towhee/dag/graph_builder.py
0.00% <0.00%> (ø)

towhee/operator/operator.py
0.00% <0.00%> (ø)

towhee/dataframe/_iterator.py
0.00% <0.00%> (ø)

towhee/dataframe/dataframe.py
0.00% <0.00%> (ø)

... and 21 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c062030...1dd29be. Read the comment docs.

/approve
/lgtm


[BUG] - Cardano Node becomes "stuck" during synchronisation without outbound connectivity

External
Area
Other   Cardano node Block synchronisation
Summary
A clear and specific description of what the bug is.
Cardano Nodes will become "stuck" and their chain will fail to proceed to the next block after entering this state. The cause appears to be a lack of outbound DNS which is not specified as a requirement within the documentation (unless I have missed it).
Steps to reproduce
Steps to reproduce the behavior:

Create a Cardano node [1] without outbound connectivity (default route) available.
Add another local Cardano node [2] to its topology file through which it will update using a private network address. Cardano Node [2] has outbound connectivity allowing it to synchronise its chain publicly.
Provide no NAT for Cardano node [1]
The Cardano node [1] will become "stuck" when syncing to certain blocks in the block chain. Restarting the node will resolve the issue ?sometimes?

Below is an example of a mainnet block which such a node became "stuck" on.
{
"epoch": 270,
"hash": "59b1aa123731e727a028a1feedd68ff7193fbe78c6095c02c4b073185941e796",
"slot": 31657148,
"block": 5827657,
"era": "Mary"
}
Expected behavior
The node should be able to receive blocks from it's local Relay and should not require DNS to function.
System info (please complete the following information):

OS Name: Ubuntu
OS Version 20.04
Node version cardano-node 1.27.0 - linux-x86_64 - ghc-8.10 git rev 8fe46140a52810b6ca456be01d652ca08fe730bf
CLI version  cardano-cli 1.27.0 - linux-x86_64 - ghc-8.10 git rev 8fe46140a52810b6ca456be01d652ca08fe730bf

Screenshots and attachments

Just leave the node running for a time, after it becomes stuck reproduce by just running "cardano-cli query tip --mainnet" multiple times.

Additional context
The typical application / reason for this configuration is a Cardano Node runs as a producer with a default DENY policy on its output chain with an ACCEPT to only the Cardano Relay and addresses for management.

Closing this. If this is still relevant please reopen.


How to send file attachment to WhatsApp Web using puppeteer

I am currently working on integrating WhatsApp functionality into my application, specifically using the WhatsApp Web URL to send messages programmatically. How can I send a file attachment using the WhatsApp Web URL?
I am currently using Puppeteer, a Node.js library for controlling headless Chrome or Chromium, to automate sending messages through WhatsApp Web. I have successfully implemented sending text messages using the following WhatsApp Web URL format:
const URL=${WHATSAPP_WEB_URL}send?phone=${number}&text=${encodeURIComponent(message)};
However, I am now facing challenges when it comes to sending file attachments along with the text message. My goal is to attach a file from a given URL to the WhatsApp message. I would like to know:

Are there any specific encoding requirements for the attachment parameter value?
What is the format or structure of the attachment parameter in the WhatsApp Web URL? Is it a separate URL, a file path, or some other format?
Are there any alternative methods or libraries within the Puppeteer ecosystem that can simplify the process of attaching files to WhatsApp messages?

This kind of question is better suited for StackOverflow. Please post it there!


Feat: Refactor existing Kusion modules

What would you like to be added?

[x] #849
[x] #850
[x] #852
[x] #851

Why is this needed?
The appConfiguration schema has been refactored and existing modules are not suitable

all done.


add insecure auth flag to deployed server

Codecov Report

Merging #801 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #801   +/-   ##
=======================================
  Coverage   47.25%   47.25%
=======================================
  Files          34       34
  Lines        2588     2588
=======================================
  Hits         1223     1223
  Misses       1178     1178
  Partials      187      187

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a30e36...5e037e5. Read the comment docs.


Efficient when

@JBBryan @tomhanlon @casecode @mona87 @glyyynn @tomfuertes - What do you think about this iteration?

:+1:

Alright, well if no one objects to this then I'm gonna push it live today.


Nginx not finding/using globalconfiguration file & TransportServers aren't working

Describe the bug
A couple of things, chaining subjects
Nginx controller

The NginxIngress CRD deployment/pod doesn't have the Command-line Arguments - -global-configuration=$(POD_NAMESPACE)/<nginx-configuration-name>

When using the NginxIngress, it doesn' t create the globalconfiguration

  yaml spec.controller.enableCustomResources: true spec.controller.globalConfiguration: <nginx-controller-namespace>/<nginx-configuration-name>
or
  yaml globalConfiguration:   create: true   spec:     listeners:     - name: example-tcp       port: 8888       protocol: TCP
The controller.service.customports contains this config, and the port is visible on the service. (should this also be done on the controller?)
   customPorts:     - name: example-tcp       port: 8888       protocol: TCP       targetPort: example-app
TransportServers
  `
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: example-tcp
namespace:
spec:
listener:
name: example-tcp
protocol: TCP
upstreams:
- name: example-app
service: example-service
port: 8888
action:
pass: example-app
  `
  `
apiVersion: k8s.nginx.org/v1alpha1
kind: GlobalConfiguration
metadata:
name: example-tcp
namespace:
spec:
listeners:
- name: example-tcp
port: 8888
protocol: TCP
  `
k describe ts -n <nginx-controller-namespace> <ts>
Type     Reason    Age   From                      Message
Warning  Rejected  37s   nginx-ingress-controller  Listener example-tcp doesn't exist
The service and deployment are in a namespace, different from where the GC & TS is.
To Reproduce
Steps to reproduce the behavior:

Deploy nginx-operator using the documentation (git clone, version -> make -> deploy etc)
Create nginx controller using NgninxIngress
Create GlobalConfiguration & TransportServer, as described above

Expected behavior

GlobalConfiguration file is created when defining it in the NginxIngress

NginxIngress is using the GlobalConfiguration

TransportServer is finding the listener

Custom TCP/UDP ports can be used when having the Nginx Controller deployed through Nginx-Operator

Your environment

Version of the NGINX Ingress Operator - v1.4.0
Version of the Ingress Controller -
Version of Kubernetes. v1.26.3
Kubernetes platform (e.g. Mini-kube or GCP). On-prem, ubuntu
Using NGINX

Additional context
Goal is that a service, with a custom TCP/UDP port (eg 8888), via Ingress object can be used with the nginx.org controller (not the Kubernetes Nginx controller (which does work with custom tcp/udp)).
If someone could explain how to achieve this, would be great 😄 And the issue related to the globalconfiguration could be fixed/explained.

Hi @D1StrX Thank you for reporting this issue. This might be due to an issue in the helm chart, as in https://github.com/nginxinc/kubernetes-ingress/issues/3753, where the command line argument should still be generated in the manifest, but the name of the GlobalConfiguration does not match the actual GlobalConfiguration created.
If this is the case, due to the way operator works, you can try the following to duplicate the existing GlobalConfiguration with the correct name
kubectl get gc nginxingress-sample-nginx-ingress -n nginx-ingress -o json \
        | jq '.metadata.name = "nginx-ingress"' \
        | kubectl apply -f -

Note that you will need to update the controller custom ports too.
Please let me know if this workaround fixes the error. We are evaluating ways to address this issue and will provide an official fix soon.

You are correct. GC named nginx-ingress and the argument in the pod matches and works now. Also the rejecting is gone on the TS, the first time.... After deploying a change to the nginx controller it breaks the TS and says 'AddedOrUpdatedWithError'
Configuration for <namespace>/<TS> was added or updated ; but was not applied: error when updating config from ConfigMap: could not get newest config version: could not get expected version: 15 after 1m0s

So the service & controller need to have the custom ports?
Then I am still wondering what is needed on the ingress part, so it works with the created GC & TS. (I have it working with kubernetes nginx controller). Are there specific annotations to be used?

I managed to get it to work as well.. but the I had to use an example from the ngnix docs.. somewhere deep in Github of nginx repo. What still doesn't work is Aacustom name for the GC. Only nginx-ingress-default-controller works (tested by letting the CRD create the config file).


Sirdata RTD Module : update module presentation

Add new features avoidPostContent & avoidPostEids
🏷 Type of documentation

[X] new feature
[X] text edit (wording, typos)

📋 Checklist

[X] Related pull requests in prebid.js or server are linked -> Paste link in this list or reference it on the PR itself
https://github.com/prebid/Prebid.js/pull/11524

Looks like the code changes for this will be in PBJS 8.51

Looks like the code changes for this will be in PBJS 8.51

That's great! Anyway, it's now PBJS 9 ready


Disabled autocorrect, autocomplete, and spellcheck

I frequently run into issues with opponent's gamertags being autocorrected, forcing me to re-enter the gamertag, which, given the short amount of time between getting your opponents and landing in, can cause issues.

To clarify, you are referring to autocorrect on iOS/Android/other touch platforms?

Looks good, thanks!

Correct. I typically use my iPad to look up opponents pre-match. And no problem! Awesome app by the way


Fixed if-statement

Hi! Fixed if-statement related to #16 since it caused parameters and request bodies to be ignored.

Tested it, it doesn't sound working. PR #27 doesn't work either

See #27


Optiscroll doesn't disable native scrollbars on Firefox on Mac

The problem happens when scrollbars are hidden by default, and shown only while scrolling:

It's weird because it takes place only on Firefox, but I could see in your website that it's perfectly fine, regardless of OS setting.

Thanks for pointing this out. I saw that an error is thrown on FF Mac when only trackpad is used.
However the custom scrollbar will not be enabled on FF Mac (on trackpad) anyway, as there is no way to hide the browser one: see https://bugzilla.mozilla.org/show_bug.cgi?id=926294.
I've pushed a new version with the fix and updated the readme with the relevant information.

Here's the odd thing - it did hide the native scrollbars on the Optiscroll demo page though

If you plug the mouse, then the plugin will still "work" because the offset right will persist. However, together with the scrollbar we are also loosing 16px of content that is now clipped.

Again, I don't understand why the emphasis on connecting a mouse - it already worked on your website, before your fix - with or without a mouse attached

It was not really working. It was wrongly clipping 16px of content out of the view. The expected behaviour on Firefox Mac is:

with mouse attached Optiscroll works as expected and hides the scrollbars
with trackpad only, Optiscroll keeps the native scrollabars as we cannot hide them with CSS

Are you using an Apple mouse? Because I'm using a Microsoft mouse (the drivers are different) and the result is the same - Native hidden scrollbars appear while scrolling, alongside Optiscroll's scrollbars (I of course used forceScrollbars: true.

Sorry, silly mistake - I didn't refresh Firefox after enabling native hidden scrollbars - that's why it was working for me. After refreshing - It doesn't work.


Error when trying to yarn build

I get the following error when executing yarn build.
Any idea what im doing wrong?
/bin/sh: 1: mage: not found
error Command failed with exit code 127.
mage -version shows:
Mage Build Tool v1.11.0-2-g4cf3cfc
Build Date: 2021-08-22T20:05:12+02:00
Commit: 4cf3cfc
built with: go1.11.6

You need to install mage. See Ubuntu build instructions.

mage -version gives me information about this. see my first comment.
i think its already installed.

is this a problem? and why yarn build try to execute mage in sh

looks like this might be a problem with where yarn build looks for the executables.
can you try mage build:backend to build the backend manually.

pi@raspberrypi:/var/lib/grafana/mqtt-datasource $ mage build:backend
Error determining list of magefiles: failed to list non-mage gofiles: exit status 1: go: finding github.com/go-logfmt/logfmt v0.3.0
this is what happend when i do mage build:backend

I've had zero problems with mage on latest master. I think this can be closed.

Alright then closing now! Thanks for reporting @terorie 👍


Add CORS headers when CORS options are present

PR to close #8
I wrapped the setting of cors headers within a if statement to check if there is a cors object on the request, this stopped a bunch of tests from failing due to json parse issues. I also removed the setting of application/json within the header just so the request can set that itself.
Lastly added a basic test to check that the headers supplied to the createHandler get passed on as expected.
Everything passes but first time doing a PR and not super familiar with typescript so feel free to update or suggest as needed!

Alright, after much effort to debug builds and tests, I think I've got this in a place I'm happy with it so I'm going to merge this and create a new release. Thanks for the contribution and my apologies for taking so long to merge it!


Lighter Runtime

What?
Replacing the current os thread-based runtime in favor of supervision trees and the option to run the entire set of extensions under a single process. All prior compatibility still exists and extensions can still run individually unsupervised.
Known issues

Config parsing using Viper is broken see issue and we have to find a way around this to support config via config files
The entire flag parsing has to be rethought now that we dug into go-micro.
Reva services are not being stopped on context cancellation.

There are more todo's and regards on the JIRA ticket.
Ticket: https://jira.owncloud.com/browse/OCIS-1715
TODO

[ ] add json tags for config files. Currently configuring Reva extensions, values are case sensitive because they get transpiled to golang type names, and these must match. Look into using struct tags.

Some Considerations:

[ ] subcommands MUST also set MICRO_LOG_LEVEL to error.
[ ] normalize flag parsing (and fix hack of renaming ocis top level for the destination side effect)
[ ] Metrics endpoint in Proxy changed, now we do not panic.  Same metrics?
[ ] config file parsing with Viper is no longer possible as viper is not thread-safe (https://github.com/spf13/viper/issues/19)

[ ] when an extension runs on supervised mode, ocis parses the global config

[ ] establish on suture a max number of retries before all initialization comes to a halt.
[ ] Reva runtime currently does not have support for closing a service when a context is canceled??
[x] reuse the runtime service struct to control suture.
[x] shutting down a service implies iterating over all the serviceToken for the given service name and terminating them.
[ ] ~to avoid this getting out of hands, a supervisor would need to be injected on each supervised service.~
[ ] ~each service would then add its execute func to the supervisor, and return its token (?)~
[x] this runtime should only care about start / stop services, for that we use serviceTokens.
[x] ~normalize the use of panics so that suture can restart services that die.~ return achieves the same effect.
[x] the runtime should ideally run as an rpc service one can do requests, like the good ol' pman, rest in pieces.
[x] remove default log flagset values.

More Considerations

[x] solve the annoying issue with:

[x] ~Failed to shutdown server error="context canceled" server=debug service=proxy~

scaling on a single node works. Example editing the config:

create /etc/ocis/proxy.json
start ocis using the runtime
modify the proxy.json config HTTP and debug ports
ocis run proxy
there are 2 proxy instances now

~deal with the error:~

~panic: send on a closed channel~

[tusd] logging format is not in sync with the rest of the services
[x] ~sharing is broken, could it be the same issue with the home storage config we had a few days ago?~ duplicate config downstream.
[x] ~when running supervised group run should not listen for OS interruptions~
does web need: //Flags: flagset.RootWithConfig(cfg), ?

Docs

Configuration via config files
As soon as #1762 gets merged, oCIS admins will be able to define a global configuration file in order to configure the entire node. Values present in such file correlate to those of ocis-pkg/config.
Naturally oCIS offers a wide range of ways to be configured, from admin friendly config files to cli flags and cloud / 12factor environment variables, but with so many sources is really easy to get lost in translation. Let's dig into precedence and operation modes.
Modes of Operation
In order to understand precedence let's define modes of operation first. Depending on how an extension runs this will be supervised or unsupervised. Think Erlang supervisors. Whenever the ocis single binary 's server command is invoked, all default embedded extensions that will bootstrap a fully functional oCIS instance with its default in-memory configuration. On the other hand, when an extension is ran standalone (picture an external extension built outside the single binary) with the single binary, i.e: ocis run idp then there is no supervision tree looking after this extension. In other words the extension is looking only after itself, and is up to it to recover from panics, restart or fork itself in case of unrecoverable states.
Simply put, ocis server runs using goroutines and supervision trees, everything else runs as a single, independent process.
Precedence
Supervised
An extension running supervised will receive and modify a configuration in the following order (from more to less relevant):

cli flags
environment variables
config files

Given the nature of oCIS, cli flags can't make it all the way to subcommands, so oCIS does not propagate cli flags down to extensions. To see the list of supported CLI flags for oCIS run ocis help.
Unsupervised

TODO

Example Global Configuration
proxy:
  http:
    addr: "<IP_ADDRESS>:6200"
accounts:
  http:
    addr: "<IP_ADDRESS>:8888"
Storage:
  Reva:
    StorageMetadata:
      Port:
        HTTPAddr: "<IP_ADDRESS>:7777"

@refs I think you got around the config parsing using a mutex, right? Tick it off from the 'known issues' list?

ok, to shutdown reva we need a context option on the runtime.RunWithOptions()...

ok, to shutdown reva we need a context option on the runtime.RunWithOptions()... but not as part of this PR

thanks for looking into this one :) I would add a follow-up ticket for the fast lane


GH3464: Add support for MSBuild 17 / VS2022

fixes #3464

@devlead your changes have been merged, thanks for your contribution :+1:


Add cache expiration support (TTL)

This PR adds support for cache expiry (TTL). This is a new feature for most consumers, but this is also a BC break because it adds a new parameter to the CacheInterface::set($name, $value, $ttl = null) signature.
As its name implies, the ArrayCache uses an array to store the optional TTL and will yield a cache miss when a cache item is expired.
Builds on top of #28, thank you @WyriHaximus for the initial version! I've squashed the original version to a single commit to preserve authorship. Unlike the initial version, this updated version uses an array for significantly faster operation (heavily inspired by https://github.com/reactphp/event-loop/pull/164).
Supersedes / closes #28
Resolves / closes #11

@jsor Good catch, updated! :shipit:


[stable/elasticsearch] Update elasticsearch from 6.8.6 to 6.8.22

Signed-off-by: chengdehao<EMAIL_ADDRESS>
What this PR does / why we need it:
Because of the bug of Log4j,Using Elastiscsearch, which has not yet been fixed, is slightly more dangerous.
elasticsearch-oss:6.8.22 has fixed this problem, so I think upgrading elasticsearch is necessary.Please see： https://www.elastic.co/guide/en/elasticsearch/reference/6.8/release-notes-6.8.22.html
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

Thank you for your PR. However, as of November 2020, we stopped accepting updates to this archival repo. More details: https://github.com/helm/charts#helm-charts - and you can find the current home of this chart here: https://github.com/elastic/helm-charts/tree/main/elasticsearch


feat: add pagination and filters

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Activation Failed in Force Tunneling and Nat to Azure IP scenario

We are trying to activate ~200 WVD instances behind one NAT ip in Azure ( not on-prem, but in Azure ) .
We managed to activate Windows10 successfully but on day 2 kms.core.windows.net starts rejects ( tcp.rst ) connections from the clients.
"Test-NetConnection -ComputerName kms.core.windows.net -Port 1688" failed.
When I applied a workaround, proposed in the article (UDR in RT) , activation succeeded and Test-NetConnection is succeeded as well.
Is there any rate-limit on kms.core.windows.net frontend that might block my ip in case of too many simultaneous connection ?

@Andriy-dev For this activation issue, I would suggest you contact Azure support for help.


Jupinx test cases

We should create an (untracked) test_jupinx.rst file with minimal examples of Jupinx bugs, so they're easily accessible from the comparison tool.

We can have it in git, but just not put it in the tree of lectures (i.e. not in any indices)?

Right, exactly. Sorry should've been more clear on "untracked"

Done.


Doesn't work for me with c++/gprof

After Profile: Open Profile -> gprof -> gmon.out   result is two opened empty editors  and notification: "Error parsing profile: 1005 -- 'utf-8' codec can't decode byte 0xf2 in position 38: invalid continuation byte"
After selecting output of gprof (the text file, instead gmon.out)  the notifcation says: "Error parsing profile: Python script exited with code 1"

Thanks for reporting! Looks like there's a bug with gprof and hatchet. I opened up an issue there [issue link]. I will follow up when there's an update.

Is there any update to this issue?
I'm also experiencing the same parsing error when I try see my gmon.out.

Hi @wme7, thanks for reaching out! My hatchet PR that fixes this just got merged yesterday. I'll test it out with the hatchet develop branch sometime this week and see if it fixes the issue in this extension.

Same here


sasl configuration - refresh callback for runtime rediscovery

Hi,
This PR proposes to allow sasl credentials configuration parameter to be callback that returns same sasl options object.
The callback will be called every time a new connection is established sasl authentication is executed, so it allows credentials to be changed during runtime and kafkajs will still reconnect.
Same background as with #854
Example:
const refreshCredentials = async() => {
  const credentials = await myCustomCredentialsService()

  return {
      username: credentials.username,
      password: credentials.secret,
  }
}

const kafka = new Kafka({
  clientId: 'my-app',
  sasl: {
    mechanism: 'scram-sha-256',
    refresh: refreshCredentials
  }
})

I had actually completely forgot that I was involved in a similar effort a year back.
I believe a good place to start is by reading https://cwiki.apache.org/confluence/display/KAFKA/KIP-368%3A+Allow+SASL+Connections+to+Periodically+Re-Authenticate, which was implemented in #496. Essentially, when we authenticate we get back a session lifetime in ms. If that amount of time (minus some threshold) has passed, Broker.isConnected will return false, which will trigger a re-authentication.
In parallel, #445 tried to implement pretty much the same thing as this PR. In one of my comments from almost exactly a year ago, I mention the need to separate "getting the current credentials" and "renewing the credentials": https://github.com/tulios/kafkajs/pull/445#issuecomment-531463534 This is similar to how it's handled in the Java client (or in Java in general) through JAAS, where a LoginModule is responsible for creating a credential class which can optionally implement the Refreshable interface, which supports the methods boolean isCurrent() and void refresh().
The comment goes into the details of it, and I think it still stands. The reason being that with the current implementation, the credentials are only renewed when a new connection is created. If the connection already exists, the credentials will not be renewed. This means that it will not play nicely with KIP-368.
So rather than evaluating sasl once when we create the connection, the connection should maintain a reference to the original sasl provider function so that we can renew the credentials when (re-)authenticating.

Hi again, sorry for long delay.
I've updated code so now the sasl update is evaluated in SASLAuthenticator.authenticate() method instead of only once inside connectionBuilder. I didn't go with the SASLProvider interface as having refresh() optional callback function was easy to use  and also implement.

I see that the SASLOptions structure changes per method... how should the rediscover API look like? Is it relevant for all methods or just scram/plain?

I think lets close it for inactivity. Workaround is that you can keep reference to configuration .sasl data object and modify it on runtime.


--DB_file for polyA database file

How to download the polyA database file?
Thanks.

we downloaded the file from PolyA_DB and integrated it with transcript end from GENCODE.

Thanks.


Change default desktop config.json

set "enable_voting": "false", "bootstrap_connections_max": "4"
to reduce load on slow PCs

I'm having trouble when I change anything on config.json, it says error deserializing config
No matter what I change I can only open the node .app if I delete the config.json file and lost all the changes.
I recently installed a node on a Mac but I'm only used to how Linux configuration works d


Custom header flicker

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?
Windows Server
Reproduction steps
Enable custom header
Refresh any page in Jenkins.
Expected Results
Smooth transitions between pages just like when custom header is not enabled
Actual Results
The header is repainted. It looks ugly and distracts.
Anything else?
No response

Specially when the header is "Thin header" in settings.
It seems the original header is painted which moves all page contents down and then the new thin header is painted, moving all page contents up again.

Duplicate of #22

yes most likely this is the cause. It happens when using jpg or png images that do not have the correct size. If you have a svg that works well.

Well it is more than that.
You can actually see that a "default" header is painted first and then the header is painted in the new style.
When the custom header has a different background color (eg red) compared to the original header (which is black), a refresh of the page or clicking on jobs etc will show that first a black background is painted and then the red custom one.
This makes the complete header flicker. The thin setting also makes the contents of the page jump vertically from the normal header height to the custom header height.
I did not try setting different logo sizes, but I can imagine that this also makes a difference between the original header and the custom one.
Overall it seems that the custom header painting is done after the original one. IMHO the custom header should replace existing painting so there is no difference in refresh or displaying of pages.

The custom header is not painted over the original header. It replaces it from the beginning. But the styling is computed dynamically on page load and I can't change that, as this is user dependent.
Is your Jenkins maybe under heavy load so that loading the css is delayed?
Maybe it is also due to the fact that the css is loaded only in the body and not in the head of the html. I think I can change that with a page decorator

@DaveRabelink @lemeurherve
Can you please check if https://repo.jenkins-ci.org/artifactory/incrementals/io/jenkins/plugins/customizable-header/51.vf593a_8b_1a_c12/customizable-header-51.vf593a_8b_1a_c12.hpi solves or improves the problem?

I've released my change. In case you still experience the problem please reopen.

Sorry didn't have time to test the incremental, but I'll let you know when we'll have deployed this new version on infra.ci.jenkins.io.

I've released my change. In case you still experience the problem please reopen.

LGTM, thanks @mawinter69!


Fix join() on key mixing Array and NullableArray

Previously failed when trying to index Dict{T} with Nullable{T} key,
since isequal(::T, Nullable{T}) returns false even if convert() works.
Fixes https://github.com/JuliaStats/DataFrames.jl/issues/1151.
(Failure on 0.6 is still due to CategoricalArrays.)

OK to merge?

What's the stack overflow about on nightly, any idea? I'm inclined to assume it isn't related but it'd be good to figure out why it's happening.

Closing in favor of https://github.com/JuliaData/DataTables.jl/pull/4.


Cleanup Engine

Locally this displayed some slight improvements in some call intense workloads whereas the global_bump benchmarks locally showed slight regression. Let's see what our GitLab runners are having to say.
Generally though this PR is not an optimization PR but rather a cleanup of the executor.

The diff coverage is 95.00%.

@@            Coverage Diff             @@
##           master     #458      +/-   ##
==========================================
- Coverage   79.44%   79.42%   -0.02%
==========================================
  Files          71       71
  Lines        6193     6198       +5
==========================================
+ Hits         4920     4923       +3
- Misses       1273     1275       +2

Impacted Files
Coverage Δ

wasmi_v1/src/engine/mod.rs
83.49% <75.00%> (-1.36%)
:arrow_down:

wasmi_v1/src/engine/executor.rs
98.40% <98.07%> (+<0.01%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Funny how benchmarks show quite the opposite from my local evaluation on the GitLab runners ...
https://github.com/paritytech/wasmi/pull/458#issuecomment-1253426440


Preload resources set crossorigin separately between css and js.

Is your feature request related to a problem? Please describe.
On Chrome If I set the preload css resources crossorigin it will give an warning and load it twice.
https://developers.google.com/web/updates/2017/12/modulepreload#ok_so_why_doesnt_link_relpreload_work_for_modules
Describe the solution you'd like
crossorigin: {
    css: null,
    js: 'use-credentials'
}

We are approaching the Nuxt 2 EOL date (June 30, 2024) - see this article for more information. I'm closing this issue as it's marked as a Nuxt 2 related enhancement and it's not a critical issue.
That doesn't mean it might not be relevant for Nuxt 3. If it is, please feel free to open a new issue (or just comment, and I can reopen it). 🙏
Thank you for your understanding and for your contribution to Nuxt! 🎉


fix: RESET_PASSWORD_EMAIL_SENT put in event types in Audit Logs

fixes: https://github.com/gravitee-io/issues/issues/6598

Duplicate gravitee-io/gravitee-access-management#1462


indexer breaking change: introduce objects_version for consistent query

Description
more context can be found in https://mysten-labs.slack.com/archives/C0578KFD9D2/p1716827736639489
Test plan
local run, some integrity & perf check is needed while will be done separately

Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:

@emmazzz

What's with the new .patch files though?

good q, they are specified in diesel.toml, otherwise diesel cmds would fail with no fire or dir error
[print_schema]
file = "src/schema/pg.rs"

[migrations_directory]
dir = "migrations/pg"


sqlite: fix inconsistent read-after-write

As far as I can tell, this fixes https://github.com/launchbadge/sqlx/issues/2099 (and I think https://github.com/launchbadge/sqlx/issues/3120, which appears to be the same)
My minimal reproduction looks like this (which is adapted from the example in https://github.com/launchbadge/sqlx/issues/2099):
use sqlx::sqlite::SqlitePoolOptions;

#[tokio::main]
async fn main() {
    let sqlite_options = sqlx::sqlite::SqliteConnectOptions::new()
        .filename("test.db")
        .busy_timeout(std::time::Duration::from_secs(5))
        .journal_mode(sqlx::sqlite::SqliteJournalMode::Wal)
        .create_if_missing(true);

    let db = SqlitePoolOptions::new()
        .acquire_timeout(std::time::Duration::from_secs(5))
        .max_connections(5)
        .min_connections(5)
        .connect_with(sqlite_options)
        .await
        .unwrap();

    sqlx::query("create table if not exists some_table (id integer primary key, name text)")
        .execute(&db)
        .await
        .unwrap();

    let name = "name";

    let (id,): (i64,) = sqlx::query_as("INSERT INTO some_table (name) VALUES ($1) RETURNING id")
        .bind(name)
        .fetch_one(&db)
        .await
        .unwrap();

    let out: (i64, String) = sqlx::query_as("SELECT id, name FROM some_table WHERE id = $1")
        .bind(id)
        .fetch_one(&db)
        .await
        .unwrap(); // => sqlx::Error no row found

    dbg!(out);
}

I can pretty easily get this code to panic on the main branch, just by running it a few times. It doesn't panic every time, as other issue reporters have noted, but it's consistent enough to notice.
With this fix, I can't get it to panic at all.
The fix in this PR works by forcing the stream here to run until completion, rather than returning early in the case that it returns rows (i.e., via a RETURNING in SQL).
As far as I can tell, this is related to how step in sqlx-sqlite/src/statement/handle.rs works:
    pub(crate) fn step(&mut self) -> Result<bool, SqliteError> {
        // SAFETY: we have exclusive access to the handle
        unsafe {
            loop {
                match sqlite3_step(self.0.as_ptr()) {
                    SQLITE_ROW => return Ok(true),
                    SQLITE_DONE => return Ok(false),
                    SQLITE_MISUSE => panic!("misuse!"),
                    SQLITE_LOCKED_SHAREDCACHE => {
                        // The shared cache is locked by another connection. Wait for unlock
                        // notification and try again.
                        unlock_notify::wait(self.db_handle())?;
                        // Need to reset the handle after the unlock
                        // (https://www.sqlite.org/unlock_notify.html)
                        sqlite3_reset(self.0.as_ptr());
                    }
                    _ => return Err(SqliteError::new(self.db_handle())),
                }
            }
        }
    }

where the SQLITE_ROW => return Ok(true), clause is causing the ExecuteIter to terminate early, before SQLite can return SQLITE_DONE, which I believe in turn means SQLite itself may not be committing the transaction: https://github.com/launchbadge/sqlx/blob/main/sqlx-sqlite/src/connection/execute.rs#L96
This SQLITE_ROW then causes this whole stream to terminate early, as it simply returns when it matches an Either::Right(row) rather than an Either::Left(SqliteQueryResult): https://github.com/launchbadge/sqlx/blob/main/sqlx-sqlite/src/connection/executor.rs#L68-L70
I think this is what is happening, and I think this PR fixes it, but please let me know if my understanding is incorrect.
Thanks!

@abonander I added a commit which changes the approach slightly to account for a test failure I saw in CI, where the test it_can_execute_multiple_statements was failing. I was was able to isolate that test locally and I believe the approach in 93d53ba fixes the issue with running multiple statements in the same fetch_one instance.

@ckampfe Could you add Fixes #3120 to the description?

@ckampfe Could you add Fixes #3120 (or another closing keyword) to the description?

@CommanderStorm Added.

@ckampfe if you rebase it should fix CI.

@abonander done!

Hey @abonander and @CommanderStorm, thank you for working with me on this PR, I appreciate it and all the work you do on this project.


Updates schema and regenerates cassettes

Developer

[x] All new ENV is documented in README
[x] All new ENV has been added to Heroku Pipeline, Staging and Prod
[ ] ANDI or Wave has been run in accordance to
our guide and
all issues introduced by these changes have been resolved or opened as new
issues (link to those issues in the Pull Request details above)
[x] Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

[ ] The commit message is clear and follows our guidelines
(not just this pull request message)
[ ] There are appropriate tests covering any new functionality
[ ] The documentation has been updated or is unnecessary
[ ] The changes have been verified
[ ] New dependencies are appropriate or there were no changes

Requires database migrations?
NO
Includes new or updated dependencies?
NO

Pull Request Test Coverage Report for Build 37d116e3855b2ca04b907c4e5e1d9f52605b21b5-PR-58

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.375%

Totals

Change from base Build 628b05d97c024cf1babbfe4a1877b1eee449181d:
0.0%

Covered Lines:
318

Relevant Lines:
320

💛  - Coveralls


.NET 4.0 support

Any way to get .NET 4.0 support?

Hi @igitur,
Yes, I think it should be possible. Currently the library is a PCL that supports .NET Core, which prevents it from also supporting .NET 4.0; but it's possible to create a specific project for 4.0 that uses the same source files. The only issue I can see is that the new reflection API (using TypeInfo) is not available in 4.0, but it should be pretty easy to work around.

Thanks.
I'd like to use this code in the https://github.com/amaggiulli/qlnet project to fix our memory leak. QLNet still has .NET4.0 as a dependency, so I can't use the NuGet package, but can I have your permission to use your code (with credit to you) and modify it a bit, e.g. I doubt we need EventArgs, and possibly not even the sender object.

Hi @igitur,
I forgot to add an explicit license, but you can consider the code to be under the Apache 2.0 license, so you can use it as you see fit. I'll try to add proper 4.0 support when I find the time.

Great, thanks.

I added the license.

I just released version 2.0, which supports .NET 4.0, .NET 4.5 and .NET Standard 1.1


Add sections about WildFly S2I compatibility

Signed-off-by: Jeff Mesnil<EMAIL_ADDRESS>

@jfdenise, Could you please review?