Since July 30 (around 3pm), Content Manager has been compiling several scripts successfully, but every execution is immediately marked as Skipped with the message Code execution cannot run. When you go to the history you can see that the scripts have not been actually executed.
The issue also occurs with the default Hello World script provided by the Console and affects multiple users.
The History tab does not show any running or queued executions.
The command request returns HTTP 200 and generates a valid executionId. However, the subsequent polling requests to queue-code.json?executionId=... always end with the execution status set to SKIPPED. The execution is created successfully, but it is never assigned to an execution instance (instance = null).
Before this issue started, one Groovy script was interrupted while it was still running. Around the same time, the Author logs showed topology changes and events related to the AEM Content Manager Execution Queue being stopped and recreated.
doRun() is never executed (no output is generated).
THIS IS ONLY HAPPENING IN PROD ENVIRONMENT.
We raised a ticket to Adobe and they told us to open an issue here with the following information:
"On the prod author we can confirm:
For ContentFragment_Inventory_Generator.groovy, ACM is executing correctly on the queue and reports success, for example:
Service [org.apache.sling.event.jobs.QueueConfiguration~acmexecutionqueue]
ServiceEvent REGISTERED Service [dev.vml.es.acm.core.code.ExecutionQueue, ..., JobExecutor] ServiceEvent REGISTERED dev.vml.es.acm.core.repo.Repo Dry run is enabled. Changes will not be committed to the repository.
... ContentFragment_Inventory_Generator.groovy|2026/8/5/8/42/... Execution succeeded '2026/8/5/8/42/..._0'
For other scripts (like Component_Inventory_Generator.groovy and those that show “Code execution cannot run / Skipped”), the failure is inside ACM’s own code, not in AEM. Around the time of your executions we see:
dev.vml.es.acm.core.code.Executor Execution failed '2026/8/5/8/18/..._2'
RepoException: Cannot commit changes to repository while saving file at path '/var/acm/execution/context/.../output/chunk1' Something nasty happened with '/conf/acm/settings/script/manual/ibaria-cheap-flights/ContentFragment_Inventory_Generator.groovy'
AEM’s job subsystem and the ACM execution queue (dev/vml.es.acm/ExecutionQueue) are configured and active, and ACM’s APIs (/apps/acm/api/state.json, /queue-code.json, /script.json) are returning HTTP 200 with no access-layer errors. We also don’t see Oak commit conflicts at the repository level for /var/acm.
So from the Adobe side:
The AEM author tier and Sling jobs are healthy.
ACM’s execution queue can run scripts successfully (as demonstrated by the CF inventory script).
The scripts that still fail are being skipped or erroring due to the ACM plugin’s own execution/output persistence logic under /var/acm/execution/context/..., not because AEM is blocking execution.
To get this fixed, the maintainers of ACM (wttech/VML) need to investigate why executions like Component_Inventory_Generator.groovy are hitting RepoException and being marked “cannot run / SKIPPED”."
Since July 30 (around 3pm), Content Manager has been compiling several scripts successfully, but every execution is immediately marked as Skipped with the message Code execution cannot run. When you go to the history you can see that the scripts have not been actually executed.
The issue also occurs with the default Hello World script provided by the Console and affects multiple users.
The History tab does not show any running or queued executions.
The command request returns HTTP 200 and generates a valid executionId. However, the subsequent polling requests to queue-code.json?executionId=... always end with the execution status set to SKIPPED. The execution is created successfully, but it is never assigned to an execution instance (instance = null).
Before this issue started, one Groovy script was interrupted while it was still running. Around the same time, the Author logs showed topology changes and events related to the AEM Content Manager Execution Queue being stopped and recreated.
doRun() is never executed (no output is generated).
THIS IS ONLY HAPPENING IN PROD ENVIRONMENT.
We raised a ticket to Adobe and they told us to open an issue here with the following information:
"On the prod author we can confirm:
For ContentFragment_Inventory_Generator.groovy, ACM is executing correctly on the queue and reports success, for example:
Service [org.apache.sling.event.jobs.QueueConfiguration~acmexecutionqueue]
ServiceEvent REGISTERED Service [dev.vml.es.acm.core.code.ExecutionQueue, ..., JobExecutor] ServiceEvent REGISTERED dev.vml.es.acm.core.repo.Repo Dry run is enabled. Changes will not be committed to the repository.
... ContentFragment_Inventory_Generator.groovy|2026/8/5/8/42/... Execution succeeded '2026/8/5/8/42/..._0'
For other scripts (like Component_Inventory_Generator.groovy and those that show “Code execution cannot run / Skipped”), the failure is inside ACM’s own code, not in AEM. Around the time of your executions we see:
dev.vml.es.acm.core.code.Executor Execution failed '2026/8/5/8/18/..._2'
RepoException: Cannot commit changes to repository while saving file at path '/var/acm/execution/context/.../output/chunk1' Something nasty happened with '/conf/acm/settings/script/manual/ibaria-cheap-flights/ContentFragment_Inventory_Generator.groovy'
AEM’s job subsystem and the ACM execution queue (dev/vml.es.acm/ExecutionQueue) are configured and active, and ACM’s APIs (/apps/acm/api/state.json, /queue-code.json, /script.json) are returning HTTP 200 with no access-layer errors. We also don’t see Oak commit conflicts at the repository level for /var/acm.
So from the Adobe side:
The AEM author tier and Sling jobs are healthy.
ACM’s execution queue can run scripts successfully (as demonstrated by the CF inventory script).
The scripts that still fail are being skipped or erroring due to the ACM plugin’s own execution/output persistence logic under /var/acm/execution/context/..., not because AEM is blocking execution.
To get this fixed, the maintainers of ACM (wttech/VML) need to investigate why executions like Component_Inventory_Generator.groovy are hitting RepoException and being marked “cannot run / SKIPPED”."