Android Build Failed

Hi,
Greetings
I am opening this issue to ask for help related to the build android app from Android Studio.
I am facing this issue, when trying to build the app. Are there any steps, I am missing. Please guide me.
Log
* What went wrong:
Some problems were found with the configuration of task ':app:extractStandardDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

Thanks again

Hi @sachinkum0009 ,
It seems that gradle is expecting gradle.properties to be at the root of the project instead of under the app subdirectory. Not sure if this is because newer versions of gradle expect it there or if we introduced some bug over time.
If you do a git pull, this is fixed in

Yes, I already tried these changes, but still it gives the error.

Do a Build->Rebuild Project. You may also  need to do a Gradle Sync if it didn't automatically do that when the files changed.

Thanks a lot.
Unfortunately, the problem is still there.
The com.google.protobuf plugin was already applied to the project: :app and will not be applied again after plugin: android

> Task :app:preBuild UP-TO-DATE
> Task :app:preStandardDebugBuild UP-TO-DATE
> Task :app:mergeStandardDebugNativeDebugMetadata NO-SOURCE
> Task :app:compileStandardDebugAidl NO-SOURCE
> Task :app:compileStandardDebugRenderscript NO-SOURCE
> Task :app:generateStandardDebugBuildConfig
> Task :app:extractDebugProto FAILED
> Task :app:extractIncludeStandardDebugProto FAILED
> Task :app:extractProto FAILED
> Task :app:extractStandardDebugProto FAILED
> Task :app:extractStandardProto FAILED
> Task :app:javaPreCompileStandardDebug
> Task :app:generateStandardDebugResValues
> Task :app:generateStandardDebugResources
> Task :app:checkStandardDebugAarMetadata
> Task :app:createStandardDebugCompatibleScreenManifests
> Task :app:extractDeepLinksStandardDebug
> Task :app:processStandardDebugMainManifest
> Task :app:mergeStandardDebugResources
> Task :app:processStandardDebugManifest
> Task :app:mapStandardDebugSourceSetPaths
> Task :app:mergeStandardDebugShaders
> Task :app:compileStandardDebugShaders NO-SOURCE
> Task :app:generateStandardDebugAssets UP-TO-DATE
> Task :app:mergeStandardDebugAssets
> Task :app:compressStandardDebugAssets
> Task :app:desugarStandardDebugFileDependencies
> Task :app:processStandardDebugJavaRes NO-SOURCE
> Task :app:checkStandardDebugDuplicateClasses
> Task :app:mergeStandardDebugJniLibFolders
> Task :app:mergeLibDexStandardDebug
> Task :app:validateSigningStandardDebug
> Task :app:writeStandardDebugAppMetadata
> Task :app:writeStandardDebugSigningConfigVersions
> Task :app:processStandardDebugManifestForPackage
> Task :app:mergeStandardDebugNativeLibs
> Task :app:mergeStandardDebugJavaResource
> Task :app:stripStandardDebugDebugSymbols
> Task :app:processStandardDebugResources
> Task :app:mergeExtDexStandardDebug

FAILURE: Build completed with 5 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Some problems were found with the configuration of task ':app:extractDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':app:extractDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.build(WorkValidationException.java:109)
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.get(WorkValidationException.java:91)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:76)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:50)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.TaskExecution$3.withWorkspace(TaskExecution.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:142)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	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:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	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)

==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
Some problems were found with the configuration of task ':app:extractIncludeStandardDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':app:extractIncludeStandardDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.build(WorkValidationException.java:109)
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.get(WorkValidationException.java:91)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:76)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:50)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:93)
	at java.base/java.util.Optional.orElseGet(Optional.java:369)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.TaskExecution$3.withWorkspace(TaskExecution.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:142)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	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:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	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 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
	at java.base/java.lang.Thread.run(Thread.java:829)

==============================================================================

3: Task failed with an exception.
-----------
* What went wrong:
Some problems were found with the configuration of task ':app:extractProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':app:extractProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.build(WorkValidationException.java:109)
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.get(WorkValidationException.java:91)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:76)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:50)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:93)
	at java.base/java.util.Optional.orElseGet(Optional.java:369)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.TaskExecution$3.withWorkspace(TaskExecution.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:142)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	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:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	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 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
	at java.base/java.lang.Thread.run(Thread.java:829)

==============================================================================

4: Task failed with an exception.
-----------
* What went wrong:
Some problems were found with the configuration of task ':app:extractStandardDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':app:extractStandardDebugProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.build(WorkValidationException.java:109)
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.get(WorkValidationException.java:91)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:76)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:50)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:93)
	at java.base/java.util.Optional.orElseGet(Optional.java:369)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.TaskExecution$3.withWorkspace(TaskExecution.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:142)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	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:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	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 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
	at java.base/java.lang.Thread.run(Thread.java:829)

==============================================================================

5: Task failed with an exception.
-----------
* What went wrong:
Some problems were found with the configuration of task ':app:extractStandardProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':app:extractStandardProto' (type 'ProtobufExtract').
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
  - In plugin 'com.google.protobuf' type 'com.google.protobuf.gradle.ProtobufExtract' property 'isTest' is missing an input or output annotation.

    Reason: A property without annotation isn't considered during up-to-date checking.

    Possible solutions:
      1. Add an input or output annotation.
      2. Mark it as @Internal.

    Please refer to https://docs.gradle.org/7.3.3/userguide/validation_problems.html#missing_annotation for more details about this problem.
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.build(WorkValidationException.java:109)
	at org.gradle.internal.execution.WorkValidationException$BuilderWithSummary.get(WorkValidationException.java:91)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
	at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:76)
	at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:50)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:93)
	at java.base/java.util.Optional.orElseGet(Optional.java:369)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:93)
	at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:34)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:43)
	at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:31)
	at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
	at org.gradle.api.internal.tasks.execution.TaskExecution$3.withWorkspace(TaskExecution.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:142)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:131)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:77)
	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:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	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 java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
	at java.base/java.lang.Thread.run(Thread.java:829)

==============================================================================

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

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.3.3/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 5s
31 actionable tasks: 31 executed

We shouldn't have to google your problems for you. Top result for the following query has your answer.
"com.google.protobuf.gradle.ProtobufExtract' property 'destDir' is missing"
https://github.com/google/protobuf-gradle-plugin/issues/537

Thanks a lot for your help and support. ❤
I have created a pull request to upgrade the protobuf gradle plugin #47


hook into new website joined

I want to create some basic data when a new website gets created on my app.
So when he does install, I'll know about it and could create initial data.
I know there is the authenticate, but how do I hook into that?
Thanks!

https://github.com/ohmybrew/laravel-shopify/wiki/After-Authentication-Job
all information there will help. you create the job, add it to your config to run inline or though a queue.

perfect!

@osiset if I want it to run only when installing the app (excluding login)
Can I reuse AuthControllerTrait @ authenticate?

@osiset if I want it to run only when installing the app (excluding login)
Can I reuse AuthControllerTrait @ authenticate?

Authenticate still runs every time it needs to get a new session, it's not only on install. You still want to use the AfterAuthenticateJob that @osiset has suggested. If you want to only run something once, you would need to track in a DB or something if that job or function has already ran. If so, just skip over it in the AfterAuthJob.
This is what I usually do for welcome emails etc - a table just logs if a shop has had an email before if they have it skips.

@Kyon147 Thank
But how to know that app has been installed before
I think compare current time with created_at field in table shop?
But it doesn't seem to be very accurate

@Kyon147 Thank
But how to know that app has been installed before
I think compare current time with created_at field in table shop?
But it doesn't seem to be very accurate
(in case I don't use any other table)

What are you trying to achieve by knowing if the app has been installed before?

@Kyon147
I want to see how many people have installed the app in the day
I use redis to count, so it is desirable to install the variable when it first installs (login, reinstall does not count)

@Kyon147
I want to see how many people have installed the app in the day
I use redis to count, so it is desirable to install the variable when it first installs (login, reinstall does not count)

Why not just add a check in the AfterAuthJob then?
Create a table like "installs" and when they install for the first time in the AfterAuthJob just add their shop id to the table, created date etc.
Then when that job fires, always check to see if their shop_id or domain exists, if they do just skip over it.
That way you have your log then. No need to mess around with the base package files as your changes will be overwritten when you update.


[KYUUBI #988] Add Kyuubi session event

Why are the changes needed?

closes https://github.com/apache/incubator-kyuubi/issues/988
How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

thank you for review, merging to master for v1.4.0


[less] How to eliminate marks of the less term expected？

In less file, I write JS directly, the console is OK, but Vscode reminds "less term expected", See below：

Excuse me，is there any way to eliminate the mark?
Thanks！
vscode version: 1.19.3
Computer system: win7

Looks like feature not documented on http://less2css.org/

@sosout In the meantime you will have to turn off validation with "less.validate": false

@aeschli Same problem, see less parser, this syntax will eval string as javascript.

Hi, Matthew Dean from the Less team here. Is there a way I could coordinate with the VSCode team to see how they're linting Less? I use VSCode to work on Less fixes, and I frequently see valid Less code flagged as having invalid or unexpected values.

Hi @matthew-dean, we currently maintain our own parser at https://github.com/Microsoft/vscode-css-languageservice/tree/master/src/parser for css, less and scss.
This is not really ideal, as we would need to update it from time to time to match the updated syntax of Less. It would be great if we can have a linter maintained by the less team to check against the up-to-date syntax for less. Currently, if people are using latest syntax of Less that VS Code cannot handle yet, we suggest them to turn off VS Code's validation and use a plugin such as https://marketplace.visualstudio.com/items?itemName=shinnn.stylelint.

@octref Thanks for responding!
If the Less team created / maintained such a linter, what sort of format / API should it return? It would be nice to provide a linter that is general purpose for any team that needs Less linting. I can't promise anything, as I'm not sure of the work involved, but it seems reasonable.

For linting, we can actually run any OS command as a VSCode task and extract the warnings/errors using regular expressions.
However, we also use our parser for code completion proposals, hovers, document symbols (outlines), color decorators, folding regions and more. To provide these, our css/less/scss language support implements the language server protocol. The LSP is an editor neutral API that has gained quite some traction across editors and IDEs. Of course this not little work but that would be the ideal API to implement... :-)

@aeschli Oh cool, I'll check it out.

@matthew-dean In particular, you can study https://github.com/shinnn/vscode-stylelint or https://github.com/Microsoft/vscode-tslint, which are great examples of integrating a linter as a LSP extension.

@aeschli

Looks like feature not documented on (...)

The official Less website lives at http://lesscss.org
Also; you may want to amend your comment and remove the link. That domain is squatted and redirects to a secondary one where ads are being served, including ones that tempt users to install browser extensions.

Still having the same problem using VS Code Version 1.27.2 (1.27.2)
Apart from "less.validate": false, any quick solution?

The fix will be in to upcoming 1.28 build.
But you can already try this in the insider build.

same question
win10 64
vscode 1.28.2


Ianc/loader raw script

Hi @iclanton, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Ian Clanton-Thuon). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


A few more usage-message tweaks

Minor stuff, but it corrects some errors in usage messages.
Signed-off-by: Ed Santiago<EMAIL_ADDRESS>

LGTM

The Ubuntu tests appear to have exploded on every recent PR

/lgtm

/approve


Wireshark trace - ambassador timeout problem when sending REST

Describe the bug
I have following setup (as visible in the attached image):
A (java process) -> B (kubernetes ambassador proxy) -> C (java service in kubernetes pod)
Communication is done using HTTPS between A and B, and then ambassador strips HTTPS and continues talking HTTP with C.
The problem I'm experiencing is that sometimes, it happens that HTTP BODY message that is being sent is not transmitted 100% between A and B, but only on B side trace I can see that it stopped for some reason (in trace on A side it is shown as all is sent OK). Then, java process in C (which is waiting for B-proxy to forward all the data) is just waiting and time-outs after 30 seconds.
You can see in the image attached, in A trace it is written that whole BODY is sent, but in trace on the B side, only half of BODY is visible (delivered). I suspect on these TCP Previous segment not captured.
You can also see that after this it just waits for 30 seconds, and times-out.
It happens pretty often in my setup. Does anyone knows what could be a problem?
Expected behavior
REST call does not timeout
Versions (please complete the following information):

Ambassador: [e.g. 0.85]
Kubernetes environment [AWS Kubernetes]

it seems that my colleague found what is wrong. There is a AWS load balancer in front of this ambassador pod, and when he recreated it - it seems to work now without any problem. I guess that one sent ACKs to client (A), but did not pass all the messages to ambassador pod (B).

In the end - this was problem on AWS side - when replacing classic load balancer with NLB everything started working OK.


[Proposal] Improve check_env

Proposal
Hey, one issue in Gymansium-Robotics was discovered, which could have been avoided if check_env was improved
Critique 1
utils.check_env.data_equivilance makes all_close comparisons, instead of equality comparison,
Line 57 at:
https://github.com/Farama-Foundation/Gymnasium/blob/806d8afe9358d9ff2b092f4a4d7ccf0b320690a8/gymnasium/utils/env_checker.py#L33-L63
proposed solution
add an exact argument to data_equivilance
and it should be used as True when env.spec.nondeterministic=False.
Note: all gymnasium & gymnasium-robotics environments pass with exact=True
Critique 2
It does not test that env.reset() properly resets the internal state, it just checks that initial observation is the same
proposed solution
for now, we can not have a solution that works across environments
Critique 3
It does test env.step()
proposed solution
add a simple check_step test function, which assumes that reset(seed) is deterministic (tested before running this function) and asserts that step is deterministic.
Motivation
No response
Pitch
No response
Alternatives
No response
Additional context
No response
Checklist

[X] I have checked that there is no similar issue in the repo

@pseudo-rnd-thoughts regarding Critique 1

is it a good idea to change the default exact argument of data_equivilance to  True?
or change the make function call to include exact=True  (at least inside env_checker.py)?

Sorry I didn't respond when this was originally posted.
I'm worried about using allequal rather than allclose due to float point numbers particularly for robotics environments.
An alternative solution for check_env is to use both allclose and allequal.
For a given observation, we first check if allequal, if False then run allclose, if all close fails then we raise an error about that otherwise we just log to the users the non-equalness as an environment can be deterministic to e-8 but not equivalent.
I know from talking to the Mujoco devs that due to physics changes / optimisations that mujoco versions are not deterministic and can produce different observations however within e-10 or so I believe.

there is no point in running allequal and then if it fails allclose, this is effectively the same as running allclose
for a given version of the mujuco library, the behavior will be 100% exact (unless we or the mujoco team make a mistake)

Keep in mind checking floats for equality is always asking for trouble. Float operations are not associative, and strictly speaking, it's not even true that a == a (nan) or a + b == a + b (precision fuckery).
If there's any GPU involved (which might be the case even in mujoco due to the brax stuff?), nothing is deterministic at that point due to the parallel execution + nonassociativity.
Some opt-in flag to enable "strict" mode might be alright, but it's still a bit of a footgun threat.

You make a good point we should not change the default Behaviour of data_eqivilence
but for check_env I believe we should use exact=true.

there is no point in running allequal and then if it fails allclose, this is effectively the same as running allclose

My suggestion would run allequal first then allclose so there are cases where the first would fail but the second won't

@pseudo-rnd-thoughts
do we agree that:
allclose(DATA) == allequal(DATA) or allclose(DATA)

I do not see the benefit to that. since check_env makes operations deterministically.


Do not sign debug builds

This make life of living on the bleeding edge slightly easier. For now I have to manually tweak configuration to build the service executable from master. It was quite annoying trying troubleshoot while something not loaded.

/cc @jtpetty


Improve code formatting, compiler warnings and JavaDoc

I would like to contribute a series of PullRequests to 2.x branch fixing up some code formatting, compiler warning and JavaDoc improvements.
This issue should serve as a container to bundle the PullRequests and maybe to discuss issues which arise.
As the plan is to NOT change any logic/behaviour I would not put this issue on the 2.x roadmap.

thank you for having a look at this @sclassen 😁

I think everything is merged, closing for now :D thnx @sclassen!


Bogus start/stop logic in carbon: Pidfile deleted before carbon stops

I think the start/stop script is a little bit bogus.
Summary
The stop command will delete the pidfile and send a signal without waiting the process to actually stop. The start command will assume the process is stoped if the file is missing.
Details

Start only checks if the pid file is not there

But maybe the pid file was removed by something.
The process might be still running and using the sockets

Stop will DELETE the pid file before sending a kill 15 signal to the process.

But Kill 15 might get ignored or might take a while to stop the process. For instance, carbon keeps a cache in memory that can take a while to flush until the process exits
Stop will success even If the pid in the file is wrong, and refers to the wrong proces.

If you run start again, the process will fail due busy resources.

Observed behaviour
Because this, restarting carbon might fail, which makes it difficult to automate deployments and requires human intervention.
Alternatively, one must implement complex scripts around carbon to be sure that the process is stop properly before close the instance.
Expected behaviour
To solve it we could:

stop should never delete the pidfile unless the daemon is really finished. IMO only the running daemon should delete it when it exists.
The stop command could ping/monitor carbon meanwhile is draining. Maybe add a "draining" state that can be monitor using an endpoint or a special command to carbon port.

Closing to check if this happens in latest version

The new implementation seem much more robust, sorry:
https://github.com/graphite-project/carbon/blob/eb5a0bbfe826aee7dafe647633ca48daf3997431/lib/carbon/conf.py#L302-L372


WIP use dump_syms as a library and handle native binaries

This is a better version of #511
It is blocked on https://github.com/mozilla/dump_syms/issues/371
It also does some of the prep work for #429 by adding infra for fetching a binary. However it's currently relying on dump_syms to unCAB mozilla binaries implicitly, so that feature would need to duplicate the logic in dump_syms, probably:
https://github.com/mozilla/dump_syms/blob/c2743d59b5aa321ade698f84b90f86b3d35a1b06/src/utils.rs#L32-L33
(You may also want to change the name that the file is saved to, currently I undo the exe -> ex_ mangling we do, but we might want to distinguish between whether the file is expected to be a cab or not...?)

New commit: I've substantially reworked breakpad-symbols to expose native file fetching APIs and implemented native unCABing of mozilla binaries (behind features).
I've also significantly reworked breakpad-symbols to be closer to "properly" asyncable. Now both SymbolFiles and file_paths are managed by OnceCells, so multiple tasks could in principle want the same file/SymbolFile, and will naturally block on it. To make things "fully" async we need to:

use join in a bunch of places in breakpad-symbols
use join in minidump-processor for all the thread stackwalks
use tokio::fs instead of std::fs where possible


Fancy Zones, multiple monitor, win scaling, some progs

Environment
Windows build number: Microsoft Windows [Version 10.0.18363.592]
PowerToys version: 0.16
PowerToy module for which you are reporting the bug (if applicable):0.16
Multi monitor setup, one 3840 x 2160 (4K) , one 1920x1200. The 4k is main monitor, the smaller one is positioned on (x , y ; -1920 , 0). this is left in the negatives.
Scaling on main (4k) is 150%; scaling for the small is 100%
Steps to reproduce
On the small screen there are two zones parting the screen in a left and right part.
Drop some programs in special Firefox, but also Win Explorer into one of those zones
Expected behaviour
Should fit into the zone
Actual behaviour
Depending on ratio program dropped is higher then visible are or wider then visible  -  parts are visible on main screen or end out of screen.
This looks similar to #893, but not the same problem.
Example

Hi @lscheffler
are you using a columns template?

Sry. No, it's a custom layout.
Ok. there I see more. The custom zones (on the small screen, non scaled) change there size if I change the scaling of the main monitor and are to large after the scaling, I didn't saw the borders.
So, in fact, the right zone of my example stretches right into to the next display and down to its size, while the left zone just goes downward. After editing the zones the programs worked perfectly.
So the problem is more with how the zones of non affected screens behave if the scaling is changed.
The behaviour of the zones on the screen re-scaled is awkward too. Switch able to keep ratio would be fine, but this is a different problem.

@lscheffler
we are in the process of finalizing the specs for the FZ editor v2, and one of the things we are considering is to not allow to use a layout created for a certain display on a display with a different size or ratio or on the same display but with a different DPI scaling, because there is no way we can handle the automatic resizing based on the DPI/ratio in a way that will always be consistent for all possible layouts. It's easier to just create specific layouts for each size/DPI scaling, since it's the only way to guarantee 100% correct positioning with pixel precision.

@enricogior
It's more that it is surprising that display A changes it's behaviour when display B gets its scaling changed by Windows. Normally it's not a big deal, I guess most folks will not change this often, but I'm setting up an new comp and it was a problem

That is something we should fix, since I suspect it's caused by the change in relative coordinates for the secondary monitor that are not picked up on the fly.
Only the primary monitor has fixed coordinates, the other monitor have coordinates that change when the coordinates of the primary monitor change (or of any other monitor that is "in between" the current monitor and the primary monitor).
Does it make sense?

Not really . Upper left of primary (the 4k) is 0,0, Upper left the screen on the left is -1920,0. This should not alter if I scale the primary. 0-LeftScreenWidth. At least that is what I can read from a window I place into the screen.

So let's revisit the exact steps to reproduce the problem that you see:

it is surprising that display A changes it's behaviour when display B gets its scaling changed by Windows

Display A is the 1920x1200 and display B is the 4K?
What are the next steps?

Sry. A and B are just names in this sentence. Primary (Windows 1) is 4k and left of is a smaller one (Windows 2) 1920x1200. I just focus and the secondary because the problem is there

OK, but can you please list the repro steps that result in the changed behavior on one monitor when changing DPI on the other?

@lscheffler
is this still happening with 0.23? https://github.com/microsoft/PowerToys/releases/download/v0.23.0/PowerToysSetup-0.23.0-x64.exe


[TC-DLOG-2.1] YAML Script has to be updated as per Test plan and VS document.

Description:
TC-DLOG-2.1

[ ] The test step 11 was missed in the YAML script. The script needs to be updated to include this step.
[ ] In test step 13 log and comment has to be update as per Verification step document.
[ ]  NOTE has to be added in the Precondition step .

Steps to reproduce:
Test step 11, 13
Test plan References:

https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/cluster/logs_diagnostics.adoc#311-tc-dlog-21-diagnostic-logs-cluster-commands-checks-with-bdx-dut_server

Verification Step Document References:

https://docs.google.com/spreadsheets/d/13zltSz50GRs_kidvobceEuIT8kAAHSK64ANyWcc3xQI/edit?gid=1542618045#gid=1542618045&range=1:1004

Yaml Script References:

https://github.com/project-chip/connectedhomeip/blob/master/src/app/tests/suites/certification/Test_TC_DLOG_2_1.yaml

Issue fixed in PR https://github.com/project-chip/connectedhomeip/pull/35201. Hence closing it.


Control keydown event propagation for window function

The keydown callback for windows now returns a boolean indicating
whether the event was handled and should not be passed on to the
control.
This is basically only a change for the windows platform because only there keydown events are handled by the window first and then passed to the control as far as I can see.
Maybe a unified event propagation across platforms would be nice for reproducable behaviour?
If that is prefered I could see what I can do to implement that.

Hi,
the event system is not yet fully implemented or planned.
I just added the "cancel" feature in commit  https://github.com/trustable-code/NiGui/commit/0fb2e474141dfe45a69644a3ba92fc83e65e34e7 . Instead of using a return value, I think it's better to use an object field. The field name should make the purpose clear and adding a field does not make exiting code incompatible.
Does this work for you?

Hi,
this works for me just fine.
I would probably expect a name like "handled" instead of "cance"l but that is just personal taste.

The name of the property can be discussed :)
"handled" looks nice, because it's an adjective.
"stopPropagation" would be also possible regarding the meaning.

+1 for "handled"


Fresh Nuget Package with Tika 1.11

I see that the pull request was merged in, any idea when we could see this released via Nuget?

Nuget was released tonight.


Replace Java-Websocket with OkHttp for WSS communications

We currently use a poorly-coded library called Java-Websocket, instead of the highly battle tested OkHttp. OkHttp supports websockets. Use OkHttp, and remove the original dependency.

Closing this as not needed -- I have improved our WSS client with auto-reconnect, keep-alive, and auto-resubscribe. Changing libraries is an option in the future, but my immediate concerns have been addressed.


ApplicationFrameHost.exe in PowerToys Run always, even when no UWP windows are open

Microsoft PowerToys version
0.47.0
Running as admin

[ ] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
Enter text into the PowerToys Run line. PowerToys Run is configured to list open windows if no additional characters are entered at the beginning of the query.
✔ Expected Behavior
Get only those windows that are running and located on the taskbar.
❌ Actual Behavior
2 lines with the ApplicationFrameHost.exe process appear in the output, the title of the first window is Parameters, the title of the second window is MicroSoft Store. Both of these windows are not open at the time of this bug (they are not on the taskbar).
Other Software
Windows 21H1. There was no such bug on previous versions.

@franky920920

Does this bug still existing in the actual release?
What is shown if the apps are open?

If the bug still exists please assign me.

@htcfreek  I'll check it tonight, I don't have my Windows notebook with me now.

I have tested it and can reproduce it. And if the apps are opened an incorrect process name (applicationframehost instead of calc) is shown.

@franky920920
Damn. The processes aren't parental ordered:

@franky920920
While working on the plugin code I think I solved the magical reason. The ApplicationFrameHost.exe windows exist because Windows preloads the app in background for faster startup. If you click on the result the app starts.
My new plugin code is able to update the name if the app has been started by the user. One solution would be to hide all windows from ApplicationFrameHost.exe or we find a way to detect if these windows have a taskbar button or not. (The problem we can get when hiding ApplicationFrameHost.exe window is when the windows are minimized and the process gets suspend. I will test this in the next time.) What do you think?

@htcfreek LGTM!

@franky920920
I have found a window property in dwm we can use to filter these windows. (Don't test it in code yet. But the solution looks good to me and I checked the window properties with an third-party app.)

@crutkas
Please update the assigned project.

The was fixed in in 0.55. Head over to https://aka.ms/installpowertoys to try it out

The code change in PR #15441 to fix this issue caused a regression with Virtual Desktops. We reverted the fix with PR #15943  and will track the implementation of an improved fix in #15887.


Add static vulnerability analysis tool (AppSec requirement)

We should have one a scanning tool enabled on the project that has a mechanism to receive and respond to alerts.
Requirements are it has good rulesets to vulnerability coverage for the language, ability to alert teams or the repository on issues, is kept uptodate with vulnerabilities as they are discovered.
Popular tools: - SonarCube, Semgrep, Drek

for which languages is this? Rust, wrappers, both?

for which languages is this? Rust, wrappers, both?

both

we'll probably want to either let it scan on PRs, or scan daily. Was there a recommendation from the team?

Regarding the tools - where did SonarQube, semgrep and drek came from? Do we have a recommendation from the AppSec? Asking because SonarQube requires a license (or running via a docker) semgrep has both a free and a paid version and Drek did not show up in any of recommended lists i found...


chore: add issue template for spanner

This is using the "new workflow" from the github UI.

This change is

.github/ISSUE_TEMPLATE/bug_report.md, line 3 at r1 (raw file):
Previously, coryan (Carlos O'Ryan) wrote…
Maybe "help us improve google-cloud-cpp-spanner" or "help us improve the Cloud Spanner C++ client library"?

oops - missed this but especially after seeing it, I think it's a good idea. will do it in another PR


confdir option can not directly set to the directory name under current directory

Problem Description
The code at proxy/config.py#L59 has a logic problem. If the confidir directly set to a folder name, it will raise the exception.
https://github.com/mitmproxy/mitmproxy/blob/f97826f62434f064ad12a5fb559ab82eaaa4cc8d/mitmproxy/proxy/config.py#L58-L63
Steps to reproduce the behavior:

create a folder named config at the current working directory
run mitmdump --set confdir=config
program exit and output: Certificate Authority parent directory does not exist:

The reason is that os.path.dirname only do the path split at the string, so 'config' -> ['','config'] and return '' as the result, and finally os.path.exists('') return False. This condition is wrong because if we set confdir to foo\bar, the certs will be generated under the bar folder not the foo folder, and also it will notice that CA doesn't exist in foo not foo\bar.
As a result, if you need to set config as confdir, you need to set confdir to ./config.
A better method to check whether the dirctory exist is os.path.exists(path) and os.path.isdir(path).
System Information
mitmdump --version
Mitmproxy: 5.2
Python: 3.8.5
OpenSSL: OpenSSL 1.1.1g 21 Apr 2020
Platform: Windows-10-10.0.19041-SP0

Thanks - please keep pointing out options that currently don't work properly!
I actually came across this same issue a few days ago as well. It piqued my curiosity because ~/.mitmproxy never exists on the first run, so how is this code actually working at all? Well, turns out it works precisely because that check is flawed and only checks for the existence of ~ and then creates a new .mitmproxy directory at some other place. 😄
This should be fixed with sans-io (#1775), the relevant commit is https://github.com/mitmproxy/mitmproxy/commit/a19a5c96f3f8191468ebce30a80060073a00f003#diff-e914533a2f6956d11df7615b5467c21a167837c34ef0be44b0bea14d9a25ddecL188-L191. I just removed the check (and we just generate directories where necessary). Let's keep this issue open for now until it's landed on master. 😃

This is fixed now, but #4358 appeared. 😄


[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1122)

🐛 Describe the bug
When downloading weights data from the PyTorch hub we get the following:
[stdlog] 2022-01-27 14:41:18,434 client           L0864 INFO | Traceback (most recent call last):
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\site-packages\torchvision\models\detection\faster_rcnn.py", line 369, in fasterrcnn_resnet50_fpn
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |     state_dict = load_state_dict_from_url(model_urls['fasterrcnn_resnet50_fpn_coco'],
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\site-packages\torch\hub.py", line 524, in load_state_dict_from_url
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |     download_url_to_file(url, cached_file, hash_prefix, progress=progress)
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\site-packages\torch\hub.py", line 394, in download_url_to_file
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |     u = urlopen(req)
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 214, in urlopen
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |     return opener.open(url, data, timeout)
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 517, in open
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |     response = self._open(req, data)
[stdlog] 2022-01-27 14:41:18,435 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 534, in _open
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |     result = self._call_chain(self.handle_open, protocol, protocol +
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 494, in _call_chain
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |     result = func(*args)
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 1385, in https_open
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |     return self.do_open(http.client.HTTPSConnection, req,
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |   File "C:\Program Files\Python39\lib\urllib\request.py", line 1345, in do_open
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO |     raise URLError(err)
[stdlog] 2022-01-27 14:41:18,436 client           L0864 INFO | urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1122)>

whereby checks of the certificate validity passed and this issue only happens on Windows (tested the same code on Linux without any problem). Downloading the same data file from a browser works fine (don't mind the loaded page, I loaded download.pytorch.org at first):

Versions
C:>python.exe collect_env.py
Microsoft Visual C++ Redistributable is not installed, this may lead to the DLL load failure.
It can be downloaded at https://aka.ms/vs/16/release/vc_redist.x64.exe
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: Microsoft Windows 10 Enterprise 2016 LTSB
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A
Python version: 3.9.0 (tags/v3.9.0:9cf6752, Oct  5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.14393-SP0
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Versions of relevant libraries:
[pip3] Could not collect
[conda] Could not collect

Similar SSL verification problems have been popping up for a while now. Unfortunately that is not related to TorchVision but rather caused by issues on the S3 side where we store the weights. It's also something we can reproduce consistently as it depends on the region from which you try to access the weights.

The surprising thing is that I don't have this problem on Linux from the same region, only on a Windows machine.


Notebook crash

Issue Type: Bug
I'm working with an SQL Notebook but it crashes frequently with "The window has crashed" popup, maybe after 10 or few actions on it.
there is no pattern to reproduce, but apparently the crash happens when editing a code section
Azure Data Studio version: azuredatastudio 1.9.0 (78a42e1d112ae3231777722b51eaf44f83ddbe55, 2019-07-10T04:31:36.998Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 1800)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.92GB (1.75GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

admin-pack
Mic
0.0.2

agent
Mic
0.41.0

import
Mic
0.9.0

profiler
Mic
0.9.0

Should have been fixed with the referenced PR. Please feel free to re-open if you see this happen again.


Image stored on the File System always has the name NULL_VALUE

The name of the images which are store in the file system and the value of the entities have all the value : NULL_VALUE.
Thus the different entities can not have there own image.

Here is the POJO :
/**
 * Created on 09/04/2015
 */
@Entity
@Table(name = "projects", uniqueConstraints = {})
public class Project extends GenericEntity {

	private static final long serialVersionUID = 1L;

    @Column(name = "name", nullable = false, length = 45)
    private String name;

    @FileReference
    @Column(name = "picture", nullable = false)
    private String picture;

	/*
    .
	.Truncated - fields
	.
	*/
	public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getPicture() {
        return picture;
    }

    public void setPicture(String picture) {
        this.picture = picture;
    }

	/*
    .
	.Truncated - Getters and setters
	.
	*/

}

And there the form creation method :
@Override
public FieldSetConfigurationUnit formView(PersistentFieldSetConfigurationUnitBuilder fragmentBuilder) {

	// @formatter:off
	return fragmentBuilder
			.field("name").caption("Name")
			.field("picture").caption("Picture")
			.field("status").caption("Status").enumeration(createEnumElements())
			.field("summary").caption("Summary").editor(textArea())
			.field("description").caption("Description").editor(wysiwyg())
			.build();
	// @formatter:on
}

The base directory has been configured in the web.xml file

@kowlown , can you see to run the tests mentioned in #202?


[SPARK-41162][SQL] Do not push down anti-join predicates that become ambiguous

What changes were proposed in this pull request?
Rule PushDownLeftSemiAntiJoin should not push an anti-join below an Aggregate when the translated (cf. aliasMap) join conditions become ambiguous w.r.t. to both join sides.
Why are the changes needed?
This example fails with distinct(), and succeeds without distinct(), but both queries are identical:
val ids = Seq(1, 2, 3).toDF("id").distinct()
val result = ids.withColumn("id", $"id" + 1).join(ids, "id", "left_anti").collect()
assert(result.length == 1)

With distinct(), rule PushDownLeftSemiAntiJoin creates a join condition (id#774 + 1) = id#774, which can never be true. This effectively removes the anti-join.
Before this PR:
The anti-join is fully removed from the plan.
*(2) HashAggregate(keys=[id#4], functions=[], output=[id#6])
+- AQEShuffleRead coalesced
   +- ShuffleQueryStage 0
      +- Exchange hashpartitioning(id#4, 200), ENSURE_REQUIREMENTS, [plan_id=19]
         +- *(1) HashAggregate(keys=[id#4], functions=[], output=[id#4])
            +- *(1) LocalTableScan [id#4]

This is caused by PushDownLeftSemiAntiJoin adding join condition (id#774 + 1) = id#774:
=== Applying Rule org.apache.spark.sql.catalyst.optimizer.PushDownLeftSemiAntiJoin ===
!Join LeftAnti, (id#776 = id#774)                  'Aggregate [id#774], [(id#774 + 1) AS id#776]
!:- Aggregate [id#774], [(id#774 + 1) AS id#776]   +- 'Join LeftAnti, ((id#774 + 1) = id#774)
!:  +- LocalRelation [id#774]                         :- LocalRelation [id#774]
!+- Aggregate [id#774], [id#774]                      +- Aggregate [id#774], [id#774]
!   +- LocalRelation [id#774]                            +- LocalRelation [id#774]

After this PR:
Join condition id#776 = id#774 is still translated into (id#774 + 1) = id#774 but recognized as ambiguous to both sides of the prospect join and hence not pushed down. The rule is then not applied any more.
The final plan contains the anti-join:
*(4) BroadcastHashJoin [id#53], [id#51], LeftAnti, BuildRight, false
:- *(4) HashAggregate(keys=[id#51], functions=[], output=[id#53])
:  +- AQEShuffleRead coalesced
:     +- ShuffleQueryStage 0
:        +- Exchange hashpartitioning(id#51, 200), ENSURE_REQUIREMENTS, [plan_id=382]
:           +- *(1) HashAggregate(keys=[id#51], functions=[], output=[id#51])
:              +- *(1) LocalTableScan [id#51]
+- BroadcastQueryStage 3
   +- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)),false), [plan_id=424]
      +- *(3) HashAggregate(keys=[id#51], functions=[], output=[id#51])
         +- AQEShuffleRead coalesced
            +- ShuffleQueryStage 2
               +- ReusedExchange [id#51], Exchange hashpartitioning(id#51, 200), ENSURE_REQUIREMENTS, [plan_id=382]

Does this PR introduce any user-facing change?
It fixes correctness.
How was this patch tested?
Unit test.

I did not manage to test this in LeftSemiAntiJoinPushDownSuite, which would be preferrably.
My approach is
  test("Aggregate: LeftAnti join no pushdown on ambiguity") {
    val relation = testRelation
      .groupBy($"b")($"b", sum($"c").as("sum"))
    val relationPlusOne = relation.select(($"b" + 1).as("b"))

    val originalQuery = relationPlusOne
      .join(relation, joinType = LeftAnti, usingColumns = Seq("b"))

    val optimized = Optimize.execute(originalQuery.analyze)
    comparePlans(optimized, originalQuery.analyze)
  }

This creates plan
Project [b#7]
+- Join LeftAnti, (b#7 = b#12)
   :- Project [(b#1 + 1) AS b#7]
   :  +- Aggregate [b#1], [b#1, sum(c#2) AS sum#6L]
   :     +- LocalRelation <empty>, [a#0, b#1, c#2]
   +- Aggregate [b#12], [b#12, sum(c#13) AS sum#6L]
      +- LocalRelation <empty>, [a#11, b#12, c#13]

while this would be required to expose the bug (both Aggregate plans have to have identical references):
Project [b#7]
+- Join LeftAnti, (b#7 = b#1)
   :- Project [(b#1 + 1) AS b#7]
   :  +- Aggregate [b#1], [b#1, sum(c#2) AS sum#6L]
   :     +- LocalRelation <empty>, [a#0, b#1, c#2]
   +- Aggregate [b#1], [b#1, sum(c#2) AS sum#6L]
      +- LocalRelation <empty>, [a#0, b#1, c#2]

@wangyum @cloud-fan appreciate your suggestion on how to test this bug in LeftSemiAntiJoinPushDownSuite (see https://github.com/apache/spark/pull/38676#issuecomment-1317220559).

@EnricoMi @cloud-fan Could we fix the DeduplicateRelations?  It did not generate different expression IDs for all conflicting attributes:
=== Applying Rule org.apache.spark.sql.catalyst.analysis.DeduplicateRelations ===
 Join LeftSemi                         Join LeftSemi
 :- Project [(id#4 + 1) AS id#6]       :- Project [(id#4 + 1) AS id#6]
 :  +- Deduplicate [id#4]              :  +- Deduplicate [id#4]
 :     +- Project [value#1 AS id#4]    :     +- Project [value#1 AS id#4]
 :        +- LocalRelation [value#1]   :        +- LocalRelation [value#1]
 +- Deduplicate [id#4]                 +- Deduplicate [id#4]
!   +- Project [value#1 AS id#4]          +- Project [value#8 AS id#4]
!      +- LocalRelation [value#1]            +- LocalRelation [value#8]

Could we fix the DeduplicateRelations?

Interesting, that sounds like a better solution. I'll look into it.

Problem is that DeduplicateRelations is only considering duplicates between left output and right output, and not duplicates between left references and right output. I have sketched a fix for Join and LateralJoin, including a proper test.
This could potentially be done for all operators specifically handled in DeduplicateRelations.apply(), i.e. AsOfJoin, Intersect, Except, Union and MergeIntoTable.
Deduplicating attributes that are already referenced will break the plan as those references break.

Can one of the admins verify this patch?

@wangyum @cloud-fan I am not sure if this is the right approach to fix DeduplicateRelations. Please advise.
Problem is that DeduplicateRelations is only considering duplicates between left output and right output, but this situation is caused by duplicates between left references and right output.

@wangyum @cloud-fan what do you think about my approach? Do you have a suggestion for a better strategy?

@wangyum @cloud-fan do you consider this issue a correctness bug?

I tried looking into this a bit

@EnricoMi @cloud-fan Could we fix the DeduplicateRelations? It did not generate different expression IDs for all conflicting attributes:

As @EnricoMi said DeduplicateRelations only considers the output attrs of the left and right, which do not conflict here. Also the Project case in PushDownLeftSemiAntiJoin calls this method which seems to check for self-join case based on conflicting expression ids. This makes me believe the duplicate expression IDs are expected here and hence DeduplicateRelations may not be at fault.
Similar to the Project case, should we add a check like canPushThroughCondition(Seq(agg.child), joinCond, rightOp) to ensure that it is safe to push the join down an Aggregate node too?

@shardulm94 you are right, canPushThroughCondition already guards Project and Union against this situation, so that should be the natural way to fix this for Aggregate as well. It is the least possible change to fix this issue.
I have created #39131, to keep it separate from this approach, which tries to fix this issue through DeduplicateRelations. Will close this PR if the other one makes it.
Thanks for the pointer!

Closed in favour of #39131.


Fix api_keies by using pluralisation library

So I dont see how this could break gorm so LGTM. @sjwhitworth What do you think?


Enable C++20

Is your feature request related to a problem? Please describe.
I would like to enable C++20 so I can use this feature https://en.cppreference.com/w/cpp/language/attributes/likely in our p2p code

https://github.com/Taraxa-project/taraxa-node/pull/1076


Add query to fetch draft orders

In the Dashboard 2.0 we want to have separate links to view draft orders and confirmed ones. For that reason we need to add a separate resolver to return only draft orders. Exiting orders resolver should be changed to return confirmed orders.

How about adding orderStatus or ``````orderStatuses``` argument which can filter the draft order or orders with any statuses in the backend for orders API?

I agree with @jxltom, a new resolver makes no sense if we have means to use filtering. We already have such argument, but it only allows filtering on two statuses:
class OrderStatusFilter(graphene.Enum):
    READY_TO_FULFILL = 'READY_TO_FULFILL'
    READY_TO_CAPTURE = 'READY_TO_CAPTURE'

It could be improved to actually use all the status choices and perhaps accept a list of status choices instead of just one.

I agree that we need to extend filtering capabilities in the orders resolver - that will be required by Dashboard 2.0 anyway at some point. But I would exclude draft status from this resolver and have a separate one for a few reasons:

drafts use different logic than regular orders - they can be edited in many ways or deleted from DB,
by having a separate field in API we make it clear to API consumers that "drafts" and "regular" orders are a bit different concepts,
draft orders are visible only to staff users - it's easier to require permission when we have a separate field for that.


fix(import): move from deprecated Document.createDocuments

This PR migrates the deprecated calls to Document.createDocuments() for temporary documents to the constructor Document() syntax.
Closes #1683

Nice!


Expand on text for post-hysterectomy language

We have discussed adding a caveat to all recommendations that account for a hysterectomy. This would expand upon the text to include language stating that you should stop screening only if you have not had a diagnosis of CIN2 or greater in the past 25 years, since this information may not be accessible to the CDS.
Something like:

“This patient has documentation of a hysterectomy. If hysterectomy was performed for treatment, patients should have 3 consecutive annual HPV-based tests before entering long term surveillance. Long term surveillance involves HPV based testing at 3-year intervals for 25 years.
Screening is generally not recommended after hysterectomy if no previous diagnosis of CIN2 or greater in the preceding 25 years and the cervix was removed at the time of hysterectomy.”

UPDATE: We will also add logic to recognize if a hysterectomy exists in the patient record without a date, and if so, to give the same general post-hysterectomy recommendation similar to the one described above.

This was resolved in Pull Request https://github.com/ccsm-cds-tools/ccsm-cds-with-tests/pull/79


GitHub Enterprise in private mode sends a 403 for info/lfs/objects/batch

When a GitHub Enterprise instance is configured in private mode, it returns 403 when a POST to https://[hostname]/testuser/testrepo.git/info/lfs/objects/batch is sent.
This causes the error:
Invalid status for POST https://[hostname]/testuser/testrepo.git/info/lfs/objects/batch: 403
error: failed to push some refs to 'https://[hostname]/testuser/testrepo.git'

Version tested is:
git-lfs/1.0.0 (GitHub; darwin amd64; go 1.5.1)
git version 2.4.9 (Apple Git-60)
Possible workarounds:

use a remote URL with a username:token in it (however, this is bad security practice)
manually set git config lfs.batch false
Set the remote to SSH instead of HTTP(S)

Unfortunately, 403 is a typical response that means something is there. It'd be really easy to change here, but would also disable the batch api in GHE 2.4+ because those also return 403 for the batch API.
I don't see how we can support this custom (and incorrect IMHO) response code without affecting other LFS servers.

Adding another workaround: connecting via SSH instead of HTTPS.
@technoweenie I agree. I think the workaround, while annoying, is better than having one-offs for each server's implementation.

Am I correct in reading that one of the workarounds is required for any private gitub repo?

Enterprise 2.4 returns 401 instead of 403, so it supports the auth workflow properly. It means public repositories still require a login, but that's the whole point of Enterprise's private mode feature.

I see.  Apologies as I'm not as familiar with the Enterprise product line.
Our organization is currently not using Enterprise, but we are using paid private repos - does this mean a workaround is required?

@boblaublaw Nope. GitHub Enterprise ships with a "private mode" feature that wraps all requests (even to public repositories or gh pages) behind authentication. Before GitHub Enterprise 2.4, private mode would return 403 responses if no authentication was passed. I changed it to 401, which is semantically correct.


TL-29693: Adding support for all universal user IDs

Type of change

[x] Feature

Description of change
Up until this point, the Triplelift bid adapter only supported PubCommon ID, Criteo ID, LiveRamp ID, and Unified ID. This feature adds additional functionality to ingest all additional user IDs that a publisher is setting on their page.
We could refactor this whole ID process at some point, but want to just get this in as is for now as a refactor will affect much of our User ID testing as well.

I suggest adding at least a test or two for one of the universal IDs, similar to this

I've tested the bulk of these ID modules. Most I can't actually get to place an ID because they require an account with the provider, but for those that don't I'm getting consistent results. There don't appear to be any surprises with how Prebid makes this data available to bid adapters and so the method we wrote to apply to our bid request looks reliable.

@patrickloughrey looks like you need to hard reset against the master branch. The 45 commits in this date back to January


Documentation website is down

ww0-1

white whale docs is down too

https://docs.whitewhale.money works now. Thanks for your submission.


x/exp/shiny: build is broken on darwin

$ go build golang.org/x/exp/shiny/...
# golang.org/x/exp/shiny/widget
widget/label.go:40: undefined: font.MeasureString
widget/label.go:41: m.Ascent.Ceil undefined (type fixed.Int26_6 has no field or method Ceil)
widget/label.go:41: m.Descent.Ceil undefined (type fixed.Int26_6 has no field or method Ceil)
widget/label.go:57: m.Ascent.Ceil undefined (type fixed.Int26_6 has no field or method Ceil)

/cc @nigeltao @crawshaw

You need to sync your golang.org/x/image repo.


Storage component not yet supported

Hi, could you tell me how difficult it is to adapt the code to plot storage nodes (also for multinetworks)? What functions I would have to modify? Best

Adding a single component is fairly straightforward.  You should look for any functions and constants with gen_* or *_gen in the name, and and those functions for storage_
This includes the function storage_plot, and parameters like storage_color, storage_size, storage_data, storage_data_type, along with defaults values for these parameters in the default_plot_attributes dictionary.
I will also say that I hope to update powerplots to be able to support arbitrary components with just supplying the types of components that are nodes and edges respectively.  However, I do not know when I will have the time to do.

All right, thank you!


Minerva v0.24

minerva v0.24.0
This small PR makes the last few changes needed to introduce minerva v0.24.0.
Updates

Copies of the License are now correct in the test suite files.
Various mypy and flake8 fixes.
Added new pre-commit.ci badge.
Added CodeFactor badge.

Removed torch.compile functionality as it seems to have a fair few bugs and issues supporting certain Python versions and causes TypeErrors within minerva which are not easy to resolve.