jibDockerBuild build randomly fails in multi-project setup with parrallel flag

Environment:
*Jib version: 3.1.2
*Build tool: Gradle v7.0.2
*OS: Ubuntu-18.04
*JDK 14,
*Java source/target compatibility 12
Description of the issue:
In a multi-project gradle project with the flag org.gradle.parallel=true, the execution of the top level jibDockerBuild target randomly fails for one of the projects.
This seems to be due to the parrallel nature of the build.
Steps to reproduce:

Multi-project with at least 7 services built as docker containers
gradle.properties set with parrallel execution
org.gradle.parallel=true
build target jibDockerBuild or the root project
Extract of the build log
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':project4:jibDockerBuild'.

com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: (null exception message)

Expected behavior:
Images for all projects created
Mitigation:
This workaround prevent the jibDockerBuild task from each individual project to run in parrallel using the jib.lock file
For each project enabling jib plugin:
// Make sure only one image is created at a time
// as it may cause to overload the socket and fail the build.
// This is done by identifying a common output file
jibDockerBuild.configure {
outputs.file "$rootDir/jib.lock"
}

@gbesancon could you get the full stack trace by running Gradle with ----stacktrace (or --debug --stacktrace if that seems more useful)?

I'm trying to reproduce it with the debug  and stacktrace on, but so far without success, though I still randomly reproduce the problem without the debug and stacktrace options.
I'm also trying to put together a sample project i could share that would reproduce the issue without the options or for which i could get the stacktrace.

Maybe try just --stacktrace without --debug, since I guess --debug may interfere concurrency somehow. Anyways, I appreciate your effort to share a sample project.

I was able to get a stacktrace for this issue, using jib 3.1.4, gradle 7.2 and JDK 16:
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: (null exception message)
* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':service:jib'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:188)
	at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:186)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:174)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
	at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
	at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
	at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:402)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:389)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:382)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:368)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: org.gradle.internal.UncheckedException: com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: (null exception message)
	at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:68)
	at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:41)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:107)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$2.run(ExecuteActionsTaskExecuter.java:502)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:74)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:74)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:487)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:470)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$300(ExecuteActionsTaskExecuter.java:106)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.executeWithPreviousOutputFiles(ExecuteActionsTaskExecuter.java:271)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:249)
	at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:89)
	at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:40)
	at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:53)
	at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:50)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
	at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:50)
	at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:40)
	at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:68)
	at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:38)
	at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:50)
	at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:36)
	at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:41)
	at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:74)
	at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55)
	at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:51)
	at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:29)
	at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:58)
	at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:39)
	at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:60)
	at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:27)
	at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:180)
	at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:75)
	at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:46)
	at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:40)
	at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:29)
	at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:36)
	at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:22)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:105)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:98)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:53)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:37)
	at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:85)
	at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:42)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27)
	at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:92)
	at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:50)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:114)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:73)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:47)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:92)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:92)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:33)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution$2.withWorkspace(ExecuteActionsTaskExecuter.java:284)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:40)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:30)
	at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:37)
	at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:27)
	at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:44)
	at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:33)
	at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:76)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:185)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:174)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
	at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
	at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
	at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
	at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:402)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:389)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:382)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:368)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: (null exception message)
	at com.google.cloud.tools.jib.plugins.common.JibBuildRunner.runBuild(JibBuildRunner.java:285)
	at com.google.cloud.tools.jib.gradle.BuildImageTask.buildImage(BuildImageTask.java:121)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
	... 118 more
Caused by: java.nio.channels.OverlappingFileLockException
	at com.google.cloud.tools.jib.filesystem.LockFile.lock(LockFile.java:68)
	at com.google.cloud.tools.jib.cache.CacheStorageWriter.writeMetadata(CacheStorageWriter.java:356)
	at com.google.cloud.tools.jib.cache.Cache.writeMetadata(Cache.java:101)
	at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.pullBaseImages(PullBaseImageStep.java:310)
	at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:157)
	at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:69)
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)

That definitely look like the kind of issue I was having and haven't been able to reproduce with a stacktrace.
I guess it's a minor detail but I was having the issue with the jibDockerBuild target not jib.

I've seen it with both tasks, though I don't have a stacktrace for when it happens with jibDockerBuild.
Besides that, I've also run into situations where jib tasks simply hang, not sure if that's also related to building in parallel...

From time to time my build hangs endlessly. Looking at the thread dump I noticed jib being stuck acquiring a file lock when retrieving metadata from the image cache
java.lang.Thread.State: WAITING (parking)
at<EMAIL_ADDRESS>Method)
- parking to wait for  <0x000000061208bc20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.10/AbstractQueuedSynchronizer.java:885)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(java.base@11.0.10/AbstractQueuedSynchronizer.java:943)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(java.base@11.0.10/AbstractQueuedSynchronizer.java:1263)
at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(java.base@11.0.10/ReentrantLock.java:317)
at com.google.cloud.tools.jib.filesystem.LockFile.lock(LockFile.java:57)
at com.google.cloud.tools.jib.cache.CacheStorageReader.retrieveMetadata(CacheStorageReader.java:102)
at com.google.cloud.tools.jib.cache.Cache.retrieveMetadata(Cache.java:192)
at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.getCachedBaseImages(PullBaseImageStep.java:446)
at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:124)
at com.google.cloud.tools.jib.builder.steps.PullBaseImageStep.call(PullBaseImageStep.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.10/Thread.java:829)

Thank you all for the reports. This is very helpful.

The OverlappingFileLockException indicates that multiple threads on the same JVM machine were able to enter into the same section of the code at the same time that is guarded by a singleton static lock.
Are you doing anything special abut the Jib tasks? For example, defining new tasks based on the default Jib tasks or configuring any additional things on them?

We don't do anything special. I also had a look at the code, but I didn't see why it would deadlock like that. On my laptop it was reproducible close to 100% of the time. Sometimes the exception, sometimes just deadlocking.

@robert-elles @pschichtel if possible, please share a full thread dump on a deadlock, as it tells which thread is blocked on which thread doing what.

Thanks for providing your workaround @bademux! Glad to know that at least running the jib tasks sequentially worked. We will keep this issue open to gather more information on how and why a multi-module setup causes issues when running in parallel.

@mpeddada1 and looks like hackfix doesn't to its job. On build agent with 16+ vCPU i got:
Execution failed for task ':http-gateway:jibBuildTar'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: (null exception message)

I'll try bug reporter workaround
jibDockerBuild.configure {
  outputs.file "$rootDir/jib.lock"
}

In the case of https://github.com/quarkusio/quarkus/issues/11903 I think the issue is that each sub-module execution of quarkus:build happens with a different classloder for class LockFile.
The multi-threading lock relies on a static ConcurrentHashMap ( https://github.com/GoogleContainerTools/jib/blob/9027c8dafb8ee12b9d37e1521caf62dfbcc3d374/jib-core/src/main/java/com/google/cloud/tools/jib/filesystem/LockFile.java#L34)
but with 3 sub-modules I see 3 different instances of lockMap.
I'm not sure if this could also happen for regular jib-maven-plugin / jib-gradle-plugin (if the plugin dependencies are different maybe ?) ?
In the case of https://github.com/GoogleContainerTools/jib/tree/master/examples/multi-module, LockFile.class classloader is the same across the sub-modules, both for Maven and Gradle.

I just stumbled over this: https://youtrack.jetbrains.com/issue/KT-46200/False-positive-for-The-Kotlin-Gradle-plugin-was-loaded-multiple-times-when-applied-kotlin-and-jvm-plugins-in-different-modules#focus=Comments-27-5060815.0-0
The last comment pretty much confirms what I assumed here: https://github.com/GoogleContainerTools/jib/issues/3347#issuecomment-1201473071
So a workaround could be to add the jib plugin to the root project directly, but with apply(false).

@pschichtel It indeed looks very plausible. I will try your workaround, but I hope there is a better way to solve it.

So far @pschichtel's workaround seems to be working for me.

In the case of quarkusio/quarkus#11903 I think the issue is that each sub-module execution of quarkus:build happens with a different classloder for class LockFile. The multi-threading lock relies on a static ConcurrentHashMap (
https://github.com/GoogleContainerTools/jib/blob/9027c8dafb8ee12b9d37e1521caf62dfbcc3d374/jib-core/src/main/java/com/google/cloud/tools/jib/filesystem/LockFile.java#L34
)
but with 3 sub-modules I see 3 different instances of lockMap.
I'm not sure if this could also happen for regular jib-maven-plugin / jib-gradle-plugin (if the plugin dependencies are different maybe ?) ? In the case of https://github.com/GoogleContainerTools/jib/tree/master/examples/multi-module, LockFile.class classloader is the same across the sub-modules, both for Maven and Gradle.

FTR, Quarkus 3.2.5+ contains a workaround for this issue: https://github.com/quarkusio/quarkus/pull/35308

@sergeykad next to a fix in jib, my fix is probably as good as it gets. Seems like quarkus is essentially doing the same thing.
@chanseokoh I guess a reasonably prominent warning somewhere in the readmes regarding loading jib multiple classloaders and using them currently should be added. For the gradle plugin the workaround (loading the plugin in the root project without applying it) could also be added to the readme. Parallel gradle builds are probably the most likely situation to encounter this issue in.

Still running into this issue. @pschichtel could you provide a quick example of loading the plugin on the root project without applying it?

https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl


How to configure codecov to stop failing PRs when coverage is decreased by the small value?

Hi,
I'm using codecov in Android library written in Java and I have the following question:
How to configure codecov to stop failing PRs when coverage is decreased by the small value?
Here I have an exemplary pull request: https://github.com/pwittchen/ReactiveNetwork/pull/153.
Here's is my codecov.yml file: https://github.com/pwittchen/ReactiveNetwork/blob/master/codecov.yml
As you can see, code coverage was decreased by 1.8% and I set the threshold to 20%, so I expected by PR to fail when code coverage will by decreased by 20% or more, but the PR failed anyway. My configuration does not work as I expect.
Can you show me, how can I configure codecov in my project, so it won't fail my PR every time when code coverage is decreased by the value lower than 20%?
I'm looking forward to your reply.
PS. I don't know if this project is the correct place for this issue. If not, please show me the place where I can report my issue.
Kind Regards,
Piotr

Ok, I see you have support project, so I'm closing issue here.


feat: beautify the progress bar with github.com/hedzr/progressbar

Looks good to me, merging -> And I'm going to make a little change and that is: Ensure the cursor is always shown

I am extremely impressed on how quickly you got this done omg


[video] Slow/lag mouse-click dragging compared to responsive zoom slider drag

Version
4.8.0
Steps to reproduce

create a chart with 5,000+ data points

have multiple series in the graph (lines and or candle), lags the more series in the chart.

add data zoom, crosshairs and tooltips

zoom in and drag with mouse (slow or lag)

zoom in and drag with data zoom slider (responsive)

What is expected?
It should be a smooth drag, something within the mouse click-drag on graph seems to be causing the glitch.
What is actually happening?
Here is a video of the screen recording to show you exactly what I'm talking about:
screen recording

If you need any more details let me know, but it seems like its an issue only with mouse click-dragging on the graph compared to the zoom slider dragging.

After further testing, it does look related to tooltip, after hiding the tooltip, it's very responsive. However, tooltips are important, so I also tested adding showDelay : 25, having just a very small delay on the tooltip has given almost perfect responsiveness in the graph.

Can you share an online demo with us?


Is there any way to visualize the attention weights when generating captions?

like this

@jamiechoi1995 have you solve it?

@jamiechoi1995 have you solve it?

no


Function values & rules results in CSS with invalid property name

Hi!
I use this package quite a lot and decided to give functions values and functions rules a go. But for whatever reason it result in badly formatted CSS.
Code like this :

becomes :

I'm not sure if it's an issue related to react-jss or just jss.
Thanks for your help and all the time you put in this project :heart:

It means you don't have proper plugins setup.


Nuru/unit test

Hi,
Attached contained few unit_test and the istanbul coverage change for your perusal .
Regard;

Tests are not passing.

@nuruddeensalihu
You need editor to support eslint, as some of your syntax does not follow our eslint rules ~

@nuruddeensalihu there's merge conflict ;)

Are you working from different forks?
If you are not, that is why may be there are more commits than necessary?
We should do a rebase for this PR, which will make all commits into a single commit.


[BUG] Shenyu-Admin > BasicConfig > Plugin list page 2 cannot display

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
I do not know when to start, the second page of  BasicConfig > Plugin cannot be displayed（empty white page），but the first and third page is OK（Page size is 12）
F12 of Chrome show this:

Expected Behavior
No response
Steps To Reproduce
No response
Environment
ShenYu version(s):2.5.0

Debug logs
No response
Anything else?
No response

And when I open Request plugin，all page of Shenyu-Admin can not display，so I have to close the Request plugin by modifing Database table (plugin.enable => 0）.
The Request plugin is in Plug in list Page 2，maybe it cause the problem?
The stacktrace of Shenyu-Admin is below:

can you execute  right SQL ？ about some plugin~


[Bug Report] Style error when using "prepend"/"append" slots on el-input-number

Element UI version
2.4.2
OS/Browsers version
Windows 10 1803
Vue version
2.5.17-beta.0
Reproduction Link
https://jsfiddle.net/coolucifer/4x0taejk/4/
Steps to reproduce
create one el-input-number, add template slot='append' or 'prepend'
What is Expected?
same as el-input with 'prepend'/'append' slots
What is actually happening?
controls = "true":

controls = "false":

InputNumber doesn't support prepend and append slots.

@Leopoldthecoder #1709
so this update has been discarded?

Yes, that update only worked until 1.1.6. And only the prepend slot actually worked without a style error: https://jsfiddle.net/qmh02fyz/2/ .

2.4.6为啥删除 “prepend” 和 “append”，前面已经使用了这两个属性，这一升级工作量太大了，能否加回啊。


LAB_01_Create a virtual network infrastructure.md

Module: 00
Lab/Demo: 01
Task: 00
Step: 00
Description of issue
The Virtual Network is created in the East US 2 region. Instructions for the Application Security Groups, Network Security Groups, and Virtual Machines say these are to be deployed to East US region. Image here confirms that the Virtual Machine is meant to be on East US 2. Network security groups can only be associated to subnets whose virtual network is in the same subscription and region.
The region in the instructions for the Application Security Groups, Network Security Groups, and Virtual Machines should be updated from ~East US~ to East US 2 to match the Virtual Network.
For reference:

Repro steps:

Create ASG and NSG in a different region than the Virtual Network
Follow instructions to create the NSG rules using the ASG.
Go to nsg-1 > Subnets > Associate
Confirm the Virtual Network is not available for selection.
Go to vnet-1 > Subnets > subnet-1 > Network security group
Confirm the NSG from the different region is not available for selection.
Attempt to create Virtual Machine in a different region than the Virtual Network.
In the Networking tab of the Virtual Machine deployment, confirm the Virtual Network in different region is not available for selection

Edits were applied.  Note: APL-5002 lab exercised are intended to be used via BYOS.  At this time APL 5002 exercises have not been tested in Skillable Cloud Slice.


Depreciate envoy_reloadable_features_cares_accept_nodata runtime

This change is to deprecate the runtime guard,
envoy_reloadable_features_cares_accept_nodata .
Signed-off-by: Shyam Govindaraj<EMAIL_ADDRESS>Commit Message: deprecate runtime guard(envoy_reloadable_features_cares_accept_nodata)
Risk Level: Low
Testing: Done
Docs Changes: N/A
Release Notes: N/A
Fixes: https://github.com/envoyproxy/envoy/issues/25009

@mattklein123  Please assign it back to me and review the PR. I have removed testcases with runtime set to false.


Limited data availability through PN, MELS, MILS, BOD endpoints

Describe the issue
When you try to access data for any dates previous to 2022-07-09, the result is an empty response. The timeframe doesn't have to be large for the request to fail, just querying data for a single settlement period for these dates results in no data response. This is seen in most of the endpoints(also the stream).
Steps to Reproduce
Steps to reproduce the behavior:

Go to /endpoint/datasets/PN or /endpoint/datasets/PN/stream
Select input parameters:
settlementDate - 2022-07-09 (or any date before)
settlementPeriod -  5 (any)
See the empty data response

Expected behaviour
Should return the PN data for the requested timeframe.
Observed behaviour
No data
Screenshots
It is working fine till dates later than 2022-07-10

No data is received for the days past 2022-07-09

Checks
Please answer the following questions for yourself before submitting an issue.

[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed
[x] I'm reporting the issue to the correct repository
[x] I'm reporting a problem and not a feature request
[x] I have added the correct labels
[x] I have added screenshots or other relevant evidence (if applicable)

@trader-short - Hi Zahid , we have task in the backlog to backfill historical data ETA November 2023.


Icon stating contact selected for Zen Morning

Draw a small sun icon next to the contact selected as "Zen Morning". It should always have the sun, as long as ZM is active on them.
When a different conversation is chosen the Icon should be active on the newly selected one. ( since only one Zen Morning contact can be set)

The initial result of the team is 3 hours.
In our experience, the team estimation error is 30%.
3 x 1.3 = 4
3.) Our insurance rate is 30%.
4 x 1.3 = 5
Full optimistic score out of 3 pessimistic out of 5 hours

done <IP_ADDRESS>


Allow Labels in Ingress Resource

Signed-off-by: Joerg Schueppel<EMAIL_ADDRESS>
What this PR does / why we need it:
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
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ x ] DCO signed
[ x ] Chart Version bumped
[ ] Variables are documented in the README.md

/ok-to-test

/approve
/lgtm


Evaluate using Profile-Guided Optimization (PGO) for the compiler

Is your feature request related to a problem? Please describe.
Not a problem - just an idea of how the compiler's performance can be improved.
Describe alternatives you've considered
Leave the things as is.
Describe the solution you'd like
I checked Profile-Guided Optimization (PGO) on many projects (including compilers) - all the results are available at https://github.com/zamazan4ik/awesome-pgo . Since this, I decided to test PGO with the Bend compiler. Below are the numbers.
Test environment

Fedora 40
Linux kernel 6.8.10
AMD Ryzen 9 5900x
48 Gib RAM
SSD Samsung 980 Pro 2 Tib
Compiler - Rustc 1.77.0-nightly
Bend version: the latest for now from the main branch on commit 0b6c3350a4e556df665ef146ac6d04e6b73bbae9
Disabled Turbo boost

Benchmark
I decided to perform PGO benchmarks on a simple scenario - bend check sorter.bend (sorter.bend took from here). For PGO optimization I use cargo-pgo tool. Release build is done with cargo build --release, PGO instrumented with cargo pgo build, PGO optimized - cargo pgo optimize build, BOLT instrumented (with PGO optimization) - cargo pgo bolt build --with-pgo, BOLT optimized - cargo pgo bolt optimize --with-pgo. The training workload is the same for PGO and PLO - bend check sorter.bend.
taskset -c 0 is used for reducing the OS scheduler's influence on the results during the benchmarks. All measurements are done on the same machine, with the same background "noise" (as much as I can guarantee).
Results
I got the following results:
hyperfine --warmup 200 --min-runs 1000 -i -N 'taskset -c 0 ./bend_release check sorter.bend' 'taskset -c 0 ./bend_optimized check sorter.bend' 'taskset -c 0 ./bend_pgo_and_bolt_optimized check sorter.bend'
Benchmark 1: taskset -c 0 ./bend_release check sorter.bend
  Time (mean ± σ):       4.4 ms ±   0.1 ms    [User: 3.0 ms, System: 1.3 ms]
  Range (min … max):     4.3 ms …   4.7 ms    1000 runs

Benchmark 2: taskset -c 0 ./bend_optimized check sorter.bend
  Time (mean ± σ):       3.8 ms ±   0.1 ms    [User: 2.5 ms, System: 1.3 ms]
  Range (min … max):     3.7 ms …   4.1 ms    1000 runs

Benchmark 3: taskset -c 0 ./bend_pgo_and_bolt_optimized check sorter.bend
  Time (mean ± σ):       3.8 ms ±   0.1 ms    [User: 2.4 ms, System: 1.2 ms]
  Range (min … max):     3.7 ms …   4.1 ms    1000 runs

Summary
  taskset -c 0 ./bend_pgo_and_bolt_optimized check sorter.bend ran
    1.01 ± 0.02 times faster than taskset -c 0 ./bend_optimized check sorter.bend
    1.18 ± 0.03 times faster than taskset -c 0 ./bend_release check sorter.bend

where:

bend_release - Release + LTO build
bend_optimized - Release + LTO + PGO optimized
bend_pgo_and_bolt_optimized - Release + LTO + PGO optimized + BOLT optimized

According to the results, PGO measurably improves the compiler's performance at least in the simple benchmark above. However, PLO (with LLVM BOLT) doesn't bring measurable improvements at least in this scenario.
For reference, I also measured the slowdown from PGO and PLO instrumentation:
hyperfine --warmup 100 --min-runs 500 -i -N 'taskset -c 0 ./bend_release check sorter.bend' 'taskset -c 0 ./bend_instrumented check sorter.bend' 'taskset -c 0 ./bend_optimized_bolt_instrumented check sorter.bend'
Benchmark 1: taskset -c 0 ./bend_release check sorter.bend
  Time (mean ± σ):       4.4 ms ±   0.1 ms    [User: 3.1 ms, System: 1.2 ms]
  Range (min … max):     4.3 ms …   5.3 ms    676 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: taskset -c 0 ./bend_instrumented check sorter.bend
  Time (mean ± σ):       6.5 ms ±   0.1 ms    [User: 4.2 ms, System: 2.1 ms]
  Range (min … max):     6.3 ms …   6.8 ms    500 runs

Benchmark 3: taskset -c 0 ./bend_optimized_bolt_instrumented check sorter.bend
  Time (mean ± σ):     157.7 ms ±   5.1 ms    [User: 30.4 ms, System: 108.6 ms]
  Range (min … max):   147.7 ms … 259.6 ms    500 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  taskset -c 0 ./bend_release check sorter.bend ran
    1.47 ± 0.03 times faster than taskset -c 0 ./bend_instrumented check sorter.bend
   35.57 ± 1.30 times faster than taskset -c 0 ./bend_optimized_bolt_instrumented check sorter.bend

where:

bend_release - Release + LTO build
bend_instrumented - Release + LTO + PGO instrumented
bend_optimized_bolt_instrumented - Release + LTO + PGO optimized + BOLT instrumented

Also, I measured binary size changes in different compilation modes (without stripping):

Release + LTO: 2.6 Mib
Release + LTO + PGO instrumented: 8.2 Mib
Release + LTO + PGO optimized: 4.6 Mib
Release + LTO + PGO optimized + BOLT instrumented: 20 Mib
Release + LTO + PGO optimized + BOLT optimized: 8.6 Mib

Further steps
I can suggest the following action points:

Perform more PGO benchmarks with other datasets (if you are interested enough in it). If it shows improvements - add a note to the documentation (the README file, I guess) about possible improvements in the compiler's performance with PGO.
Probably, you can try to get some insights about how the code can be optimized further based on the changes that the compiler performed with PGO. It can be done via analyzing flamegraphs before and after applying PGO to understand the difference.
More intensive testing Post-Link Optimization techniques (like LLVM BOLT) would be interesting too (Clang and Rustc already use BOLT as an addition to PGO). However, I recommend starting from the usual PGO since it's a much more stable technology with much fewer limitations.

I would be happy to answer your questions about PGO and PLO.
By the way, it can be an interesting idea to evaluate PGO optimization applicability to the Bend program itself, not just for the compiler and similar tools (formatters, etc.).
P.S. Please do not treat the issue like a bug or something like that - it's just an improvement idea. Since the "Discussions" functionality is disabled in this repo, I created the Issue instead.

I had no idea that this was a builtin option in the Rust compiler, very cool.
Some thoughts about this:

Adding PGO to the Bend build looks very promissing, probably will be done at some point.
Bend goes out of the way to have as few dependencies as possible, especially at its core. So I doubt link-time optimizations will improve too much.
The Bend compiler is NOT optimized, almost at all. Our focus so far has been on correctness and simplicity. Before investigating compile optimizations, we'll have to profile and optimize the logic of Bend itself, which I imagine will bring much greater improvements.
I'm much more interested in the performance this can bring to the runtime. We should try doing this to the C runtime. I imagine that for CUDA, PGO is not really a thing?

Bend goes out of the way to have as few dependencies as possible, especially at its core. So I doubt link-time optimizations will improve too much.

Probably - at least it should improve the binary size. This optimization is already enabled (so I changed nothing for this in the build scripts).

The Bend compiler is NOT optimized, almost at all. Our focus so far has been on correctness and simplicity. Before investigating compile optimizations, we'll have to profile and optimize the logic of Bend itself, which I imagine will bring much greater improvements.

Yep. However, even after performing manual optimizations with a higher probability PGO still will be useful. All modern "mature" compilers like Clang, Rustc, GCC, and many others still have large performance benefits from enabling PGO for them.

I'm much more interested in the performance this can bring to the runtime. We should try doing this to the C runtime. I imagine that for CUDA, PGO is not really a thing?

It depends. If we talk about GPU code - yes, PGO is not a thing yet for it. If we talk about the CPU part - PGO should work as for regular non-CUDA code.


How to filter headers of request and response in AccessEventCompositeJsonEncoder

Please check this
https://stackoverflow.com/questions/63283432/how-to-filter-headers-of-request-and-response-in-accesseventcompositejsonencoder

The version was 4.4 😕


Webpack internal EntryPlugin does not work with multiple entries

Feature request

EntryPlugin does not produce multiple chunks in the case multiple entries are present. Currently, EntryPlugin always produces one chunk. If you try to pass an array of entries there it fails with a TS error, as it's not supported:
(property) metadataFetcher: string[]

What is the expected behavior?
Entry plugin produces as many entries as passed in the parameters.
What is motivation or use case for adding/changing the behavior?
Consistency between EntryPlugin and webpack entry configuration. It unlocks usage of EntryPlugin for the applications with multiple entries.
How should this be implemented in your opinion?
Accept an array of entries, compile each.
Are you willing to work on this yourself?
No. I am not aware what are the reasons why MultiEntryPlugin is deprecated in latest Webpack, seems like this functionality was present in Webpack4 but removed.

@adragich Sorry for delaty, still valid?


Update v1.5 files

Update user guide images
Add tests for greater coverage
Add avatar for all contact cards
Update task stick on task deletion

Coverage increased (+1.4%) to 86.789% when pulling 0fa9f93daf29219eed2a5398391cc6a47c935f98 on lancehaoh:v1.5-tmp into d8a5db5b10275fa6b2136316a02701fda70f0f47 on CS2103AUG2017-W11-B1:master.


deal with partial img tags

Some browsers will tolerate img tags without a closing '>', ex. <img src="http://image.src.com"
This would not be stripped by the current implementation and would create an img tag in some browsers.

Hey @yeslad, thank you so much for this PR. I am very sorry for the long wait after you put in this work. This project and my motivation were in a bad spot. I recently breathed new life into it (http://locutus.io/2016/05/announcing-locutus/). Unfortunately for your PR this also means it's currently outdated and cannot be merged as is.
I'll close this issues, but if this PR is still relevant to you, please re-open. You should then rebase with this project's master branch, make sure it complies with the contributing document (https://github.com/kvz/locutus/blob/master/CONTRIBUTING.md), and then we can merge this in, because the work really does look good to me.
Again, I'm very sorry for not having giving this the attention it deserves earlier, and putting you through all this extra hassle. That's all on me and being overrun by this project. I hope you'll agree though that the project was in a dead-end street, and with this new big push, we're going somewhere again.

Actually, I just noticed there might still be some issues in this function also where it deviates from PHP behavior, that is not the intention of this project


[bug] Cannot initialize the training job when the user uses 1 worker and 0 PS

There are some users want to use TFJob to run local training jobs with Estimator. They will have such a config:
 spec:
    tfReplicaSpecs:
      Worker:
        replicas: 1
        template:
          spec:
            containers:
            - command:
              - /bin/bash
              - -c
              - python cifar10_main.py --data-dir=/clever/input/datasets/cifar10
                --job-dir=/tmp/cifar10 --num-gpus=0 --train-steps=1000

One worker will be created with TF_CONFIG:
{
    "cluster": {
        "worker": [
            "tensorflow-190911-rr84s-worker-0.tsk.svc:2222"
        ]
    },
    "task": {
        "type": "worker",
        "index": 0
    },
    "environment": "cloud"
}

The estimator will try to load TF_CONFIG from the env var.  then it will get the config.
But we do not expect this. We should not set TF_CONFIG for this scenario.

Here is an example: https://github.com/tensorflow/models/tree/master/tutorials/image/cifar10_estimator
We cannot use 1 worker to run the example with tf-operator.

/cc @johnugeorge @richardsliu
I can fix it
/assign @gaocegege

In Pytorch, it is validated to have 1 Master with 0 or more workers

@johnugeorge Will pytorch-operator set MASTER_ADDR in this master pod?

I think so. But, it would not matter even if it does it

Gotcha. TF_CONFIG has a side effect in this case.


Error importing linegraph.csv

This worked well before, but after recent plugin updates is now giving error message: 组件出错了，请核查后重试： data.filter is not a function.
I imported the line graph like this: data: linegraph.csv
This also gives error message: data.line: linegraph.csv

Show me your sample, thx.
#-----------------#
#- chart type    -#
#-----------------#
type: Line

#-----------------#
#- chart data    -#
#-----------------#
data: LineData.csv

#-----------------#
#- chart options -#
#-----------------#
options:
  xField: 'time'
  yField: 'temperature'
  meta:
    time:
      type: 'time'
      mask: 'MM-DD'
      nice: true
      tickInterval: 172800000
      range: [0, 1]
    temperature:
      sync: 'temperature'
      alias: '温度'
  geometries:
    - type: 'line'
      xField: 'time'
      yField: 'temperature'
    - type: 'point'
      xField: 'time'
      yField: 'temperature'
      mapping:
        shape: 'circle'
        style:
          fillOpacity: 1

LineData.csv

Problem solved. It seems I lost the Charts View Settings at the last Obsidian upgrade (and Templater settings too, but not other plugins). I re-set the data folder for loading chart data, and the chart again rendered properly. I should have checked before posting. Sorry to have bothered you with this.

Problem solved. It seems I lost the Charts View Settings at the last Obsidian upgrade (and Templater settings too, but not other plugins). I re-set the data folder for loading chart data, and the chart again rendered properly. I should have checked before posting. Sorry to have bothered you with this.

No worries.


refactor(build -- dts): merge all dts into 1 file

Adjust dts generation so that site generator can work with it.
@jdanyow @EisenbergEffect

This looks pretty straight forward and a small change to this library. @jdanyow Can you give this a quick look? I'd like to get this merged this weekend so I can do a new site docs release with this content and a few others. Thanks!

looks great to me, tried it locally. Thanks @bigopon :100:


Should there be a GetTokenChallenge method for Client?

You can getTokenChallenge using js-threads on server-side, to get a challenge that can be sent back to the client for signing, and eventual verification of user identity. If you are running Go on your server, you'd probably need to have a similar flow. Right now we have a GetToken() method for threads client, that gets a token challenge, signs the challenge using the identity, and submits the signed challenge to get back the token.
Would it make sense instead to take out the getting the challenge bits from GetToken and putting it in a separate method, GetTokenChallenge, that would enable a workflow similar to what is possible through js-threads? If yes, I would like to work on a quick PR.

Hey @samikshan, it's probably useful if you're running into this question, though I'm not totally clear on the use case. The challenge you get from this standalone method GetTokenChallenge, what would the caller do with that?

@sanderpick Hey. Sure, let me elaborate a bit on the use case which is basically a try at implementing authentication in my app as explained in the documentation: https://docs.textile.io/tutorials/hub/production-auth/. The difference is that I am trying to use Go (Echo framework) for the server. So,

The client, creates an identity (a key pair)
The client sends a token request to the server (with the public key)
The (Go) server requests for a challenge for the new token request and sends the challenge via websocket back to the client (this is where it would probably help to have a GetTokenChallenge() method?)
The client signs the challenge and responds back to the server.
The server verifies the signed challenge and responds back with the auth tokens to the client to complete the authentication.

Ah, okay that helps. Why not just have your client directly get a token from the threads server (threadd / hubb / buckd)?

Yeah exactly. I have taken that approach and am considering an entirely serverless design for my application. But for cases as described above, where the server (implemented in Go) would need to verify and store the public keys of users, this method would probably help.

Sorry for the delay here! Okay, that makes sense. I'm all for having as much flex as possible.

Closing as stale, feel free to reopen if you still need this / are working on it.


Azure: cannot get credentials: Name or service not known

When I run az acs kubernetes get-credentials --resource-group=$AZURE_RG_NAME --name=$AZURE_SERVICE_NAME, I see the following error:
[Errno -2] Name or service not known
Traceback (most recent call last):
  File "/home/bacongobbler/bin/azure-cli/local/lib/python2.7/site-packages/azure/cli/main.py", line 37, in main
    cmd_result = APPLICATION.execute(args)
  File "/home/bacongobbler/bin/azure-cli/local/lib/python2.7/site-packages/azure/cli/core/application.py", line 157, in execute
    result = expanded_arg.func(params)
  File "/home/bacongobbler/bin/azure-cli/local/lib/python2.7/site-packages/azure/cli/core/commands/__init__.py", line 343, in _execute_command
    raise ex
gaierror: [Errno -2] Name or service not known

Flipping on --debug does not show any further information on the issue either.

FYI this is with the v2.0.0 CLI:
><> az --version
azure-cli (2.0.0)

acs (2.0.0)
appservice (0.1.1b5)
batch (0.1.1b4)
cloud (2.0.0)
component (2.0.0)
configure (2.0.0)
container (0.1.1b4)
core (2.0.0)
documentdb (0.1.1b2)
feedback (2.0.0)
iot (0.1.1b3)
keyvault (0.1.1b5)
network (2.0.0)
nspkg (2.0.0)
profile (2.0.0)
redis (0.1.1b3)
resource (2.0.0)
role (2.0.0)
sql (0.1.1b5)
storage (2.0.1)
vm (2.0.0)

Python (Linux) 2.7.9 (default, Jun 29 2016, 13:08:31)
[GCC 4.9.2]

I have a feeling this is because I created the resource group in canadaeast, but then had to create the acs cluster in westus because canadaeast is not a valid region for acs. I'm just creating another resource group and cluster to verify.

that was indeed the issue. Creating a new resource group in westus, then creating the acs cluster in that resource group fixes things. Closing!

cc @vdice, does this fix the issue for you as well?

thanks @bacongobbler ; it didn't appear to help (had the same idea as mentioned in https://github.com/deis/workflow/issues/755#issuecomment-284573315) but will give it a fresh try today and respond w/ any new info.

Still hitting issues with bootstrapping an acs cluster, but with a different error that was originally written here; Filed an issue in azure-cli#2405.


Prevent YOURLS from displaying encryption warning when password is provided via environment variables

Code of Conduct

[X] I agree to follow this project's Code of Conduct.

Submission validity

[X] This is not a personal support request, that should be posted on discussions community.
[X] I checked current issues and this request isn't a duplicate of an existing issue, opened or closed.

Summary
Since YOURLS 1.7 as per documentation, the software automatically encrypts passwords.
This is not true (of course) for the user provided by environment variables (e.g. Docker).
Motivation
Just an annoying little error that does not cause any harm but still, it's an error which is actually not true.
Describe the solution
Check if the array contains only one element (the usual case when providing YOURLS_USER via environment variable) and if true check if the YOURLS_USER and YOURLS_PASS variables are set from environment, in case both checks are true do not even bother to call the function that tries to encrypt the password.
Maybe, just a quick, dirty solution (first that came in my mind, feel free to propose / do something else).
Thanks!

A valid point, thanks for raising. Will look into this.

Maybe I can refresh some PHP memories and take a look into creating a PR for this if it's welcome (I don't code PHP from quite a while, since my PHP 8.0 framework that I built).....

If you can look into this that would be great, indeed!
How I see things after quick toughts :

function yourls_hash_passwords_now() is best left unmodified. Its goal is to hash, not to decide if it should hash.
the test for an env var would be then introduced at includes/auth.php#L44 with a new function like yourls_user_is_from_env() or something like this
a unit test for this new function would be neat

Thoughts ?

Thoughts ?

Nothing concrete yet, I still haven't touched the codebase nor have I looked at how things are structured so that I can formulate a serious proposal about how to implement this.


fix: fixing auth issues when accessing private registries using mirroring

Description
This change is fixing the authentication issues when accessing private registries using mirroring. The focus here is the mirror image mapping should happen before the credentials and AWS region are discovered.
Looking into the code, currently the credentials are being mapped per container at workload level in the submitScanJob function here, however the mirror mapping is only happening afterwards at plugin GetScanJobSpec level here, so the credential is being mapped for the original registry server instead of the target mirrored repository. In my humble opinion this logic should be updated, from the workload perspective the credentials should be passed to the plugin in a raw mapping, containing the registry server and the auth credentials, then from inside the public, once the mirroring mapping is done, the logic of mapping each container can be executed.
Related issues

Close #1064
Close #1065

Checklist

[x] I've read the guidelines for contributing to this repository.
[x] I've added tests that prove my fix is effective or that my feature works.
[ ] I've updated the documentation with the relevant information (if needed).
[ ] I've added usage information (if the PR introduces new options)
[ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).

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

@rodrigorfk thanks you for the contribution , I'll be able to review it tomorrow

@rodrigorfk  I have made some tests , its look like the basic follow of imagePullSecret second option doesn't work on your PR , could you please check it.
I'm testing now all other options as well and I'll add tests so we have private registries covered by testing

lgtm 🚀


OAuth does not send DefaultScope variable

The DefaultScope variable in the github.go file is never sent via OAuth to github. When a user authorizes for the first time it does not send the user:email scope and the login process will fail.
To Recreate:
Log into github, go to settings-Applications and revoke any old Drone applications.
Start drone and try to log in. You will get a user email not found error, because Drone doesn't have permission to access emails.
Workaround:
Add a "scope" variable to your config.toml file. For example:
[auth]
client = "CLIENTID"
secret = "SECRET"
authorize = "https://github.com/login/oauth/authorize"
access_token = "https://github.com/login/oauth/access_token"
request_token = ""
scope= ["repo","repo:status","user:email"]
Thanks,
Phil Winder

is this in the 0.4 branch?

Correct, 0.4.0 branch.

@philwinder: Thanks you for this workaround

fixed to use default value


List additional columns in Custom Resource view

Custom Resource Definitions may additionalPrinterColumns that are
specific to a give api version.  The CustomResourceHandler and
CustomResourceListHandler were only handling top-level
additionalPrinterColumns that apply to all columns regardless of
version.  This change handles version-specific additionalPrinterColumns.
This change addresses https://github.com/vmware-tanzu/octant/issues/405

Note that this is failing the unit test due to an unrelated bug in the internal representation of CRDs in octant, discussed here https://github.com/vmware-tanzu/octant/issues/405#issuecomment-564126293 . Wayne Witzel suggested in the octant slack channel that this is being addressed in another PR.

Hello, I'm going to close this PR because I want to fix a bigger problem around CRDs that will make this change redundant. Thanks for pointing this issue out, and we'll have a fix pretty soon.

I revamped the CRD system in #490. Should solve this problem and a couple of others. Please retest when you get a chance.


[CI] builds failing due to @ibma/aat

Describe the bug
PR builds began failing yesterday in Travis CI due to an issue with the external server that is used to validate the accessibility rules through @ibma/aat
Reached out to the team on internal slack, they've fixed it for us for now. They notified me that the package we're using is being deprecated and we need to migrate to a new package, accessibility-checker.
This morning it appears builds are passing, but we need to upgrade the package to avoid this in the future.

:tada: This issue has been resolved in version 2.98.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Parent/Child relationship

Hey,
I have a 'Parent' named column inside the 'Category' table in my database. 'Parent' is foreign key to the same table ofcourse. ( pointing to 'ID' ).
I'm trying to create a restful server, that follows jsonapi.org guidelines.
and of course im implementing it using this superb library!
i came across this issue where i can fetch one resource without any problem, the parent is included inside the 'inlcuded' attribute. but when im fetching an array of resources i got the following error message

PHP Catchable fatal error:  Argument 1 passed to Neomerx\JsonApi\Document\Presenters\ElementPresenter::setRelationshipTo() must be of the type array, null given, called in /vendor/neomerx/json-api/src/Document/Document.php on line 253 and defined in /vendor/neomerx/json-api/src/Document/Presenters/ElementPresenter.php on line 54

My table Category Structure ( example )

ID
Description
Parent

1
Main
null

2
Laptop
1

3
PC
1

4
Screen
2

5
Big
4

6
small
4

my Category Model contains a property called 'Parent' of type ModelCategory
CategoryModel gets filled using a ModelHydrator that gets its data from the ModelMapper ( provider)
weird enough! when I'm fetching only one resource , its working normally. But when i try to fetch a collection, an error is thrown.
I tried to change the Parent Model, swap it with another model , it worked...

maybe its an error that occurs only when including same model in the structure?
any clue? is anyone having this issue?

ps: i'm not allowed at the moment to upload the files that i'm working on, due to restrictions :/ but i will, after creating a sample that reproduce this error.

@geniuscd An example that reproduces this issue would be much appreciated.

added test that reproduce the issue https://github.com/neomerx/json-api/tree/feature/issue91/tests/Extensions/Issue91

Fixed. Test has been moved to develop branch https://github.com/neomerx/json-api/tree/develop/tests/Extensions/Issue91

wow, that was fast! I didnt even build a sample code! thanks for the swift reply.
what I did is downloaded the src folder from the develop branch, and replaced it in my vendor/neomerx folder, and just fetch the resources.
I can confirm that now it displays the data as expected. but the inlcuded attribute is excluded :P, that means when I fetch a single resource, its working.. but again when i fetch a collection, the included attribute is missing.
should we create an new issue for it? or just continue working on #91?

@geniuscd If resource is within main and included it is removed from included.
included is excluded from output if it is empty.

@neomerx could you please share a link where jsonapi v1.0 states what you mentioned?

@geniuscd Nope, I propose you to find in the spec where it is prohibited :smile: Logically it doesn't make any sense to duplicate a resource in included if it is already on main list. As for empty included why do you think this empty section should be in output? Does it make any difference?

I think the relevant bit is here: http://jsonapi.org/format/1.0/#document-compound-documents

A compound document MUST NOT include more than one resource object for each type and id pair.

So each pair of type and id can only appear once in the document - either in included or somewhere in data, but not in both.

@neomerx totally right for the empty included attribute. +1 for that, I already though of it, it useless to include it.
@lindyhopchris thank you. I missed the compound document :)
well i think the issue is fixed .. happy to collaborate :)

will be closed when merged to master


Fix typo and variable declaration order in product.js

scripts/sections/product.js, this.productSingleObject needs to be initialized before using it in options object.

line 59, scripts/sections/product.js, this.$featured_image is not a defined variable (it's a typo), needs to be replaced with this.$featuredImage

What are you trying to accomplish with this PR?
Some basic fixes in scripts/sections/product.js
Please provide a link to the associated GitHub issue.
Checklist
For contributors:

[ ] I have updated the docs to reflect these changes, if applicable.

For maintainers:

[ ] I have :tophat:'d these changes.

Good catch. Thanks! Will deploy a patch release now.

sweet!

The same typo as on line 59 can be found on line 127 as well: this.$featured_image should be this.$featuredImage.

@sebpettersson on it!


3.2.alpha1.official produces multiple debug errors when breakpoint set in loaded script.

Godot version:
3.2.alpha1.official
OS/device including version:
Mac OS X Mojave
Issue description:
Multiple debug errors when breakpoint set in a loaded script from the main scene.
E 0:00:01:0044   is_refusing_new_network_connections: No network peer is assigned. Unable to get 'refuse_new_connections'.
  <C++ Error>    Condition ' !network_peer.is_valid() ' is true. returned: false
  <C++ Source>   core/io/multiplayer_api.cpp:822 @ is_refusing_new_network_connections()
  <Stack Trace>  somescript.gd:4 @ _init()
                 TestScript.gd:5 @ _ready()

Main Scene

Loaded script

Steps to reproduce:
Create a Main Control scene and add the following code:
extends Control
func _ready():
	var MySomescript = load("somescript.gd")
	var myInst = MySomescript.new()
	pass

Then create the script somescript.gd and add the following code:
extends SceneTree
var somevar = 20
var foo1='abcd'
func _init():
	print(foo1)

Run without breakpoints, no is_refusing_new_network_connections errors appear.
Set a breakpoint on the var somevar = 20 line. Run the project and notice the multiple debugger errors.

CC @Faless @Geequlim

To clarify, does this happen together with https://github.com/godotengine/godot/issues/32533#issuecomment-539228135?
If so that's probably just a consequence of #32533 and should now be fixed. You could not set up the debugger so debugging then doesn't work (it could however be handled more gracefully by Godot).

To clarify, does this happen together with #32533 (comment)?

Yes, it still happens.
This is partly a regression, in part it's been like this in 3.1 too.
Specifically, there are 2 issues, with the live edit and debugger (both related to the fact that refuse_new_network_connections shows the error when no network_peer is set in the SceneTree):
1
(Also present in 3.1) SceneTree.refuse_new_network_connections spits an error as soon as there is a breakpoint inside the SceneTreee script as the debugger tries to send all it's property to the editor (happen once, right after breakpoint).
#0  MultiplayerAPI::is_refusing_new_network_connections (this=0x6433db0) at core/io/multiplayer_api.cpp:822
#1  0x0000000002b2111e in SceneTree::is_refusing_new_network_connections (this=0x938a570) at scene/main/scene_tree.cpp:1795
#2  0x00000000015a8f03 in MethodBind0RC<bool>::call (this=0x69ffd70, p_object=0x938a570, p_args=0x0, p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:593
#3  0x00000000038941de in ClassDB::get_property (p_object=0x938a570, p_property=..., r_value=...) at core/class_db.cpp:1069
#4  0x00000000039178ed in Object::get (this=0x938a570, p_name=..., r_valid=0x0) at core/object.cpp:494
#5  0x0000000003b03513 in encode_variant (p_variant=..., r_buffer=0x0, r_len=@0x7fffffffbc28: 152, p_full_objects=true) at core/io/marshalls.cpp:1107
#6  0x0000000003965393 in ScriptDebuggerRemote::_put_variable (this=0x57b8a30, p_name=..., p_variable=...) at core/script_debugger_remote.cpp:111
#7  0x0000000003966587 in ScriptDebuggerRemote::debug (this=0x57b8a30, p_script=0x6500340, p_can_continue=true, p_is_error_breakpoint=true) at core/script_debugger_remote.cpp:240
#8  0x00000000014f0547 in GDScriptLanguage::debug_break (this=0x6500340, p_error=..., p_allow_continue=true) at modules/gdscript/gdscript_editor.cpp:241
#9  0x00000000015166f3 in GDScriptFunction::call (this=0x6f273e0, p_instance=0x6caa270, p_args=0x7fffffffc9c0, p_argcount=0, r_err=..., p_state=0x0)
    at modules/gdscript/gdscript_function.cpp:1503
#10 0x00000000014b5b84 in GDScript::_create_instance (this=0x938c0f0, p_args=0x7fffffffc9c0, p_argcount=0, p_owner=0x938a570, p_isref=false, r_error=...)
    at modules/gdscript/gdscript.cpp:114
#11 0x00000000014b5f7f in GDScript::_new (this=0x938c0f0, p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at modules/gdscript/gdscript.cpp:165
#12 0x00000000014dadf8 in MethodBindVarArg<GDScript>::call (this=0x6b87ed0, p_object=0x938c0f0, p_args=0x7fffffffc9c0, p_arg_count=0, r_error=...) at ./core/method_bind.h:344
#13 0x000000000391a2c9 in Object::call (this=0x938c0f0, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at core/object.cpp:921
#14 0x00000000014b94ae in GDScript::call (this=0x938c0f0, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at modules/gdscript/gdscript.cpp:655
#15 0x00000000039bf3bb in Variant::call_ptr (this=0x7fffffffc960, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_ret=0x7fffffffc9a8, r_error=...) at core/variant_call.cpp:1083
#16 0x0000000001513abc in GDScriptFunction::call (this=0x6fc06d0, p_instance=0x74b83e0, p_args=0x0, p_argcount=0, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:1079
#17 0x00000000014bd045 in GDScriptInstance::_ml_call_reversed (this=0x74b83e0, sptr=0x93cd1a0, p_method=..., p_args=0x0, p_argcount=0) at modules/gdscript/gdscript.cpp:1195
#18 0x00000000014bd0cd in GDScriptInstance::call_multilevel_reversed (this=0x74b83e0, p_method=..., p_args=0x0, p_argcount=0) at modules/gdscript/gdscript.cpp:1202
#19 0x0000000002ae6de8 in Node::_notification (this=0x933fe20, p_notification=13) at scene/main/node.cpp:149
#20 0x000000000147fed0 in Node::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/main/node.h:46
#21 0x0000000001480517 in CanvasItem::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/2d/canvas_item.h:166
#22 0x0000000001480bc7 in Control::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/gui/control.h:48
#23 0x000000000391a442 in Object::notification (this=0x933fe20, p_notification=13, p_reversed=false) at core/object.cpp:931
#24 0x0000000002ae71d6 in Node::_propagate_ready (this=0x933fe20) at scene/main/node.cpp:196
#25 0x0000000002ae715a in Node::_propagate_ready (this=0x6d09490) at scene/main/node.cpp:188
#26 0x0000000002af40f6 in Node::_set_tree (this=0x6d09490, p_tree=0x6aee870) at scene/main/node.cpp:2550
#27 0x0000000002b193d4 in SceneTree::init (this=0x6aee870) at scene/main/scene_tree.cpp:454
#28 0x0000000001400d7e in OS_X11::run (this=0x7fffffffd5b0) at platform/x11/os_x11.cpp:3180
#29 0x00000000013f0a3f in main (argc=8, argv=0x7fffffffdd48) at platform/x11/godot_x11.cpp:56

2
(Only present in 3.2) That same error is spammed by the debugger which constantly sends the properties of the selected object ID to the remote inspector.
#0  MultiplayerAPI::is_refusing_new_network_connections (this=0x6433db0) at core/io/multiplayer_api.cpp:822
#1  0x0000000002b2111e in SceneTree::is_refusing_new_network_connections (this=0x938a570) at scene/main/scene_tree.cpp:1795
#2  0x00000000015a8f03 in MethodBind0RC<bool>::call (this=0x69ffd70, p_object=0x938a570, p_args=0x0, p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:593
#3  0x00000000038941de in ClassDB::get_property (p_object=0x938a570, p_property=..., r_value=...) at core/class_db.cpp:1069
#4  0x00000000039178ed in Object::get (this=0x938a570, p_name=..., r_valid=0x0) at core/object.cpp:494
#5  0x000000000396aada in ScriptDebuggerRemote::_send_object_id (this=0x57b8a30, p_id=1184) at core/script_debugger_remote.cpp:640
#6  0x00000000039669a5 in ScriptDebuggerRemote::debug (this=0x57b8a30, p_script=0x6500340, p_can_continue=true, p_is_error_breakpoint=true) at core/script_debugger_remote.cpp:291
#7  0x00000000014f0547 in GDScriptLanguage::debug_break (this=0x6500340, p_error=..., p_allow_continue=true) at modules/gdscript/gdscript_editor.cpp:241
#8  0x00000000015166f3 in GDScriptFunction::call (this=0x6f273e0, p_instance=0x6caa270, p_args=0x7fffffffc9c0, p_argcount=0, r_err=..., p_state=0x0)
    at modules/gdscript/gdscript_function.cpp:1503
#9  0x00000000014b5b84 in GDScript::_create_instance (this=0x938c0f0, p_args=0x7fffffffc9c0, p_argcount=0, p_owner=0x938a570, p_isref=false, r_error=...)
    at modules/gdscript/gdscript.cpp:114
#10 0x00000000014b5f7f in GDScript::_new (this=0x938c0f0, p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at modules/gdscript/gdscript.cpp:165
#11 0x00000000014dadf8 in MethodBindVarArg<GDScript>::call (this=0x6b87ed0, p_object=0x938c0f0, p_args=0x7fffffffc9c0, p_arg_count=0, r_error=...) at ./core/method_bind.h:344
#12 0x000000000391a2c9 in Object::call (this=0x938c0f0, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at core/object.cpp:921
#13 0x00000000014b94ae in GDScript::call (this=0x938c0f0, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_error=...) at modules/gdscript/gdscript.cpp:655
#14 0x00000000039bf3bb in Variant::call_ptr (this=0x7fffffffc960, p_method=..., p_args=0x7fffffffc9c0, p_argcount=0, r_ret=0x7fffffffc9a8, r_error=...) at core/variant_call.cpp:1083
#15 0x0000000001513abc in GDScriptFunction::call (this=0x6fc06d0, p_instance=0x74b83e0, p_args=0x0, p_argcount=0, r_err=..., p_state=0x0) at modules/gdscript/gdscript_function.cpp:1079
#16 0x00000000014bd045 in GDScriptInstance::_ml_call_reversed (this=0x74b83e0, sptr=0x93cd1a0, p_method=..., p_args=0x0, p_argcount=0) at modules/gdscript/gdscript.cpp:1195
#17 0x00000000014bd0cd in GDScriptInstance::call_multilevel_reversed (this=0x74b83e0, p_method=..., p_args=0x0, p_argcount=0) at modules/gdscript/gdscript.cpp:1202
#18 0x0000000002ae6de8 in Node::_notification (this=0x933fe20, p_notification=13) at scene/main/node.cpp:149
#19 0x000000000147fed0 in Node::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/main/node.h:46
#20 0x0000000001480517 in CanvasItem::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/2d/canvas_item.h:166
#21 0x0000000001480bc7 in Control::_notificationv (this=0x933fe20, p_notification=13, p_reversed=false) at ./scene/gui/control.h:48
#22 0x000000000391a442 in Object::notification (this=0x933fe20, p_notification=13, p_reversed=false) at core/object.cpp:931
#23 0x0000000002ae71d6 in Node::_propagate_ready (this=0x933fe20) at scene/main/node.cpp:196
#24 0x0000000002ae715a in Node::_propagate_ready (this=0x6d09490) at scene/main/node.cpp:188
#25 0x0000000002af40f6 in Node::_set_tree (this=0x6d09490, p_tree=0x6aee870) at scene/main/node.cpp:2550
#26 0x0000000002b193d4 in SceneTree::init (this=0x6aee870) at scene/main/scene_tree.cpp:454
#27 0x0000000001400d7e in OS_X11::run (this=0x7fffffffd5b0) at platform/x11/os_x11.cpp:3180
#28 0x00000000013f0a3f in main (argc=8, argv=0x7fffffffdd48) at platform/x11/godot_x11.cpp:56

To clarify, does this happen together with #32533 (comment)?
If so that's probably just a consequence of #32533 and should now be fixed. You could not set up the debugger so debugging then doesn't work (it could however be handled more gracefully by Godot).

For me #32533 happens when I Quit To Project and then re Edit again. I don't know if that is related to this.

yes it is still reproducible.

it is now fixed after the 3.2.1 update

I can still reproduce in 3.2.1 stable.

got same error on 3.2.2.stable.mono.official
E 0:00:00.932   is_refusing_new_network_connections: No network peer is assigned. Unable to get 'refuse_new_connections'.   <C++-Fehler>  Condition "!network_peer.is_valid()" is true. Returned: false   <C++-Quellcode>core/io/multiplayer_api.cpp:833 @ is_refusing_new_network_connections()   <Stacktrace>  MeshUtils.gd:112 @ rotate()                 testMeshUtil.gd:19 @ testRotateNotEqual()                 testMeshUtil.gd:9 @ _ready()

This still happens on 3.2.3
I have noted that this happens whenever you hold a reference to the scene tree. The script below illustrates the behavior:
extends Node
func _ready():
	breakpoint
	var the_tree = get_tree()
	breakpoint

Prior to getting the scene tree reference, there is no error. But as soon as there is a scene tree reference, for every step in the debugger, the message below will be printed
ERROR: No network peer is assigned. Unable to get 'refuse_new_connections'.
   At: core/io/multiplayer_api.cpp:833

Hi,
I think that I'm getting the same issue in Godot 3.3 (stable).
As suggested above, the following line seem to trigger the error :
var tree = get_tree()
Workaround : Using only get_tree() without referencing it in a variable.


Not working with Tracker Enabled DBContext

Hi Great Package
I was hoping you could shed some light as to why your package does't work when trying to use it with
Tracker Enabled DBContext
https://github.com/bilal-fazlani/tracker-enabled-dbcontext
TEDB uses attributes where yours inherits from Trackable
where Trackable does initialize but the events never fire.
 static Trackable()
        {
            Triggers<Trackable>.Inserting += entry => entry.Entity.Inserted = entry.Entity.Updated = DateTime.Now;
            Triggers<Trackable>.Updating += entry => entry.Entity.Updated = DateTime.Now;
        }

Any help will be appreciated.

Hi, thank you,
My guess is that you're inheriting from TrackerContext which doesn't call the trigger-firing code of my DbContextWithTriggers.
If that is indeed the case the solution is simple: you need to override the SaveChanges methods in your context class. You can see how to do this here https://github.com/NickStrupat/EntityFramework.Triggers/blob/master/README.md#manual-overriding-to-enable-triggers

Strange that is what I did but for some reason, SaveChangesAsync does not override. when calling SaveChanges() all works well.

Ah, I checked what TrackerContext is doing. It's overriding the DbContext.SaveChanges... overloads, as well as defining several new overloads. Usually the two overloads just forward default arguments to the actual implementation.
So, you'll need to override all declarations of SaveChanges to call the corresponding SaveChangesWithTriggers.... Be careful overriding the new overloads declared by TrackerContext.

hello.
I had the same problem , I have create a new "TrackerContext"  ( copy form the original ) and change the SaveChanges to SaveChangesWithTriggers
see
`
        public virtual int SaveChanges(object userName)
    {
        if (!TrackingEnabled) return this.SaveChangesWithTriggers(base.SaveChanges);

        dynamic metaData = new ExpandoObject();
        _metadataConfiguration?.Invoke(metaData);

        _coreTracker.AuditChanges(userName, metaData);

        IEnumerable<DbEntityEntry> addedEntries = _coreTracker.GetAdditions();
        // Call the original SaveChanges(), which will save both the changes made and the audit records...Note that added entry auditing is still remaining.
        int result = this.SaveChangesWithTriggers(base.SaveChanges);
        //By now., we have got the primary keys of added entries of added entiries because of the call to savechanges.

        _coreTracker.AuditAdditions(userName, addedEntries, metaData);

        //save changes to audit of added entries
        this.SaveChangesWithTriggers(base.SaveChanges);
        return result;
    }`

Hi there,
Are you overriding all of the overloads correctly?

it's working 👍


Duplicate property error

Same model that I had under 4.29 is breaking under 5.0.0 with an error
Microsoft.OData.ODataException : Multiple properties with the name 'Id' were detected in a resource or a complex value. In OData, duplicate property names are not allowed.
at Microsoft.OData.DuplicatePropertyNameChecker.ValidatePropertyUniqueness(ODataProperty property)
...
at Microsoft.OData.JsonLight.ODataJsonLightPropertySerializer.WriteProperty(ODataProperty property, IEdmStructuredType owningType, Boolean isTopLevel, Boolean allowStreamProperty, IDuplicatePropertyNameChecker duplicatePropertyNameChecker)
at Microsoft.OData.JsonLight.ODataJsonLightPropertySerializer.WriteProperties(IEdmStructuredType owningType, IEnumerable`1 properties, Boolean isComplexValue, IDuplicatePropertyNameChecker duplicatePropertyNameChecker)
at Microsoft.OData.JsonLight.ODataJsonLightWriter.StartResource(ODataResource resource)
The class concerned has an inheritance hierarchy Party -> Person | Company and a parent Owner property.
I've ruled out a straightforward problem with a parent relationship by hacking one of my entities locally which works fine and I've added a similar model into the samples but it works :-(

Can this be something with resolution of names? What if you try Strict name resolver (can be set in Settings)?

The problem occurs in V4 RequestWriter.WriteEntryPropertiesAsync line 80...
 await entryWriter.WriteStartAsync(entry).ConfigureAwait(false);
With any of the NameResolvers I get
"An item with the same key has already been added"

Thanks. I will run your sample and try to figure out what's going on.

Found the actual problem, TypeUtils.GetAllProperties is being too aggressive in that it's not just collecting public properties, its also getting them from interfaces.
So my class looks like this...
public class Party : IIdentifiable
{
      public int Id { get; set; }

      object IIdentifiable.Id => Id;
      ...
}

So when it flattens the properties we get
{
  { [Id], 0 },
  [ [IIdentifiable.Id], 0 }
}

Which is where the duplicate Id reference comes from.
What I'll do is write some tests for TypeUtils.GetAllProperties so I can see how we can limit it a bit more

I've pushed a simple change to my v5 branch which filters out explicit interface implementation. This is quite tricky from the various SO answers so my one is just a first-try.
The long term solution I think is to refactor to provide a more coherent interface for determining which properties to use and to cache this to avoid the reflection overhead on each process

Thank you. I merged your code into v5 branch in my repo.


Disabling weekends to be selected

Is it possible to disable selection of weekend days

Duplication of #146. Sorry I was searching the wrong way.


Update README.md

when i add it, it removes colors.

Those comments were aimed at people with earlier versions on the settings, I've updated the readme so it should be clearer now.

thanks!


M1 based macOS between 2-3x slower than the Intel

Example of before and after:
https://cirrus-ci.com/task/4541429968535552

https://cirrus-ci.com/task/5354105359564800

This is going to hurt during the occasional peaks coming from PRs raised by our many contributors, especially as there's on only one instance allowed to run across the three repositories using the macOS runners in our GH organization.

I had a look into getting possible funding to switch to a paid plan, but of the options available, none of them actually fit us.  We are neither a private personal, nor a private organization.  Rather, a not-for-profit public organization maintaining open-source projects - perhaps the wording of the plan descriptions is terrible?

Could it be that you run still running x86 binaries under Rosetta? This log line looks a bit suspicious.

Could it be that you still running x86 binaries under Rosetta? This log line looks a bit suspicious.

Yes, the reference D compiler has no ARM backend - sadly, unfortunately, sigh. :-)

That might explain the slowness. 😪 Even though the M1 instances has 4 cores instead of 6 cores with hyper-threading like the old Intel instance, we only saw performance improvements thought out our users.
As per the options, it seems there are three of them:

Support Arm backend. But it might be too much to ask. 😅
Use compute credits to increase parallelism for master branch.
If you happen to have Intel Macs at you disposal, you can configure them as persistent workers.

On a side note. At the moment Cirrus CI's parallelism limits are enforced on per-user basis and not on per-organization so each contributor has one instance to run PRs on.

That might explain the slowness. sleepy Even though the M1 instances has 4 cores instead of 6 cores with hyper-threading like the old Intel instance, we only saw performance improvements thought out our users.

OK. Is it possible that the FAQs are still out of date?
https://cirrus-ci.org/faq/#are-there-any-limits

As per the options, it seems there are three of them:
1. Support Arm backend. But it might be too much to ask. sweat_smile

Given that there are both GCC and LLVM backed D compilers, I see two chances of updating the Zortech/DigitalMars back-end to spew out ARM object code - fat and slim. :-)

2. Use [compute credits](https://cirrus-ci.org/pricing/#compute-credits) to increase parallelism for `master` branch.

How many CPUs are used if compute credits are available? It's not too clear from the documentation, compared to, say the Linux docs, where it says you can tune CPU requirements as-needed in the config, e.g:
linux_task:
  name: Ubuntu 22.04
  container:
    image: ubuntu:22.04
    cpu: 4
    memory: 8G

The FAQs say the macOS VMs are not configurable.

On a side note. At the moment Cirrus CI's parallelism limits are enforced on per-user basis and not on per-organization so each contributor has one instance to run PRs on.

That's good to know.  So when I am having to update all three repositories simultaneously, the long wait for all pipelines to finish is just me. :-)


Static Analysis: forgotten return statements

As described in: https://github.com/ethereum/solidity/issues/3026#issuecomment-334399052

I don't know why the browser test fails. Can not reproduce it. Did not get the test to run locally...

@yann300 do you have any idea why the test could fail?

I am not familiar with the static analyzer but the changes look reasonable.

@chriseth can you review this please?

failing tests are a mistery sometimes... I think rebasing would help . could you do that?

@yann300: did the rebase. still the tests fail. Could you check if they run on your machine?

@soad003 @yann300 this now seems to pass the tests?

yes I think we can merge now, I will just add browser-test right after the merge cause static analysis report formatting changed a bit (it should return a yoyo element and not a string)

@yann300 merged this now since I wasn't sure when/how you would want to add those tests. Sorry if I've messed up something with it.


Break out Quotations into separate plugin

Do this by making Quotations plugin have "Random Quotation" shortcode which can be given a category parameter, and then making the main HF plugin accept content to be displayed on setback, success, etc. This content would be processed for shortcodes before displaying.

The code that add the categories (register_taxonomy and wp_insert_term code in the main plugin file) can probably be left in the main plugin as it should fail silently (hopefully).


action: use build.sh in docker image

Signed-off-by: William Roberts<EMAIL_ADDRESS>

needs: https://github.com/TrustedComputingGroup/pandoc/pull/30

I'm closing this, It seems as though I can just start to add to the pandoc repo, and once that is all golden we can go around and update callers if need be.


Don't save unlimited amounts of scraped hiscores

Cap player hiscores to the 30 most recent per scraping offset.

Implemented with cf0603c603496b0dc44d34b1446c2604027c65b8


POST /events/{id}/teams

Path: /events/{id}/teams
Method: POST
Description:
Adds new teams to event
Auth: COORDINATOR
Payload:
{
  teams: [Team]
}

Response:
{
  name: String,
  begin: Date,
  end: Date,
  themes: [String],
  id: Number,
  teams: [Team],
  packages: [{
    template: Package,
    avaliable: Boolean
  }],
  items: [{
    item: Item,
    avaliable: Number
  }],
  meetings: [Meeting],
  sessions: [Session]
}

Notes:
id corresponds to an _id index of mongodb.
Status codes:

Code
Rule

404
Specified object not found

400
Payload missing fields

200
Otherwise

Tests:

No event with id
Should return a status code 404.

Missing field on payload
Should return a 400 status code.

Valid info
Should return the event with the new teams

This doesn't need to exist. The created teams (by POST on /teams) should be added to the current event.

If the need to add teams to events other than the current one ever emerges, this might be useful. Closing for now then.


Unhandled "error" event

There is a weird error when someone signs up

Then it just crashes... help?

The mongoose version in package.json needs to be updated.
This is the root error
Error [MongoError]: Unsupported OP_QUERY command: insert. The client driver may require an upgrade. For more details see https://dochub.mongodb.org/core/legacy-opcode-removal     at Function.MongoError.create (D:\Repositories\Chat\node_modules\mongodb-core\lib\error.js:31:11)     at D:\Repositories\Chat\node_modules\mongodb-core\lib\connection\pool.js:497:72     at authenticateStragglers (D:\Repositories\Chat\node_modules\mongodb-core\lib\connection\pool.js:443:16)     at Connection.messageHandler (D:\Repositories\Chat\node_modules\mongodb-core\lib\connection\pool.js:477:5)     at Socket.<anonymous> (D:\Repositories\Chat\node_modules\mongodb-core\lib\connection\connection.js:333:22)     at Socket.emit (node:events:513:28)     at addChunk (node:internal/streams/readable:315:12)     at readableAddChunk (node:internal/streams/readable:289:9)     at Socket.Readable.push (node:internal/streams/readable:228:10)     at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {   ok: 0,   code: 352,   codeName: 'UnsupportedOpQueryCommand' }
Please see this documentation for more details.
https://www.mongodb.com/docs/v6.0/release-notes/6.0-compatibility/#legacy-opcodes-removed


:package: feat: Add requests package

Description
Init requests package
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #508

PR #505

PR #509   👈

PR #503

This comment was auto-generated by Graphite.


Resolving conflicts with Require.js

When trying to embed an ember app into a require js app by copying the produced javascript files, the loader.js module conflicts with the variables defined by require.js.
While not necessarily an issue with loader.js, is there a solution to embedding ember apps into require.js apps?

there is a plan to offer a no-conflict build, which attempts to wrap all ember-clis build artifacts in a closure.

Thanks. An Iframe saved the day today :dancers:

@pedrokost famous last words :P

Any updates on this ?


DNM: Make yamllint error parseable

so annotations from container logs feature detect them
add an error to test the feature

Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

/retest

/retest

Codecov Report

Merging #977 (43d651e) into main (d7e5034) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #977      +/-   ##
==========================================
- Coverage   60.94%   60.89%   -0.05%
==========================================
  Files          89       89
  Lines        5932     5928       -4
==========================================
- Hits         3615     3610       -5
- Misses       1969     1971       +2
+ Partials      348      347       -1

Impacted Files
Coverage Δ

pkg/adapter/tls.go
86.66% <0.00%> (-1.57%)
:arrow_down:

pkg/provider/gitlab/gitlab.go
80.14% <0.00%> (-0.61%)
:arrow_down:

pkg/git/git.go
74.28% <0.00%> (-0.08%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Primitive types format

#3112 doublon with a Suggestion to customize format with implementation attribute.
So you can reach a binary object like this :
@Schema(implementation = Byte.class, format = "binary")

Thanks! included and replaced by #3468


380: Initial implementation of moving_product operation

Closes #380
Implemented initial setup for moving_product in Temporian. Added method stubs and began C++ integration.
ToDo:

[x] Add test
[x] Add docs
[x] Run Code Formatter (Black)
[  ]Maybe add it under temporian/temporian/beam

Hi @akshatvishu I just tested this locally and found a couple of small things:

[ ] The example in event_set_ops.py line 3200 fails because the result is expressed in exponential notation due to the size of the results. Adjust the notation or use smaller values in the input.
[ ] Add the cumprod operation as a moving_prod with an infinite window length (cumsum for reference). As you can guess from the implementation, this is going to be pretty slow so add some warnings on the documentation and we will add a todo to optimize it in the future.
[ ] In the do you mention that "If the window does not contain any non-missing, non-zero values, the output for that window is missing (NaN)." I'd like a test checking that this is the case.

Other than these small things the PR is looking great, I think we can merge this after these points are addressed.

Congrats and thanks on the huge contribution @akshatvishu! 💪🏼

Congrats and thanks on the huge contribution @akshatvishu! 💪🏼

Big thanks to @javiber  for his  blazing fast reviews and suggestions. Couldn't have done this without his guidance 🙏


add label and gotolabel for integer labels

Adding the option to use labels to goto will enhance the feature by 10000%.

First of all, a label function should save the current line into a dictionary of labels and lines, then the goto will just use it.
Secondly, we could use something like my pybracket package to allow plain labels, e.g. label:.

First of all, a label function should save the current line into a dictionary of labels and lines, then the goto will just use it.

This only works for jumping backwards to already seen code. If the label is further down, it wouldn't be in the dictionary.

Not if you execute it in the preprocessing...

Secondly, we could use something like my pybracket package to allow plain labels, e.g. label:.

So adding a codec. I have no experience with this, but it sounds interesting. If i have some spare time, i will try it (probably sometime within a month of writing this).

K, if I will have time I'll do it myself