Checking SnapLogic docs, here's a thorough breakdown of what's happening and the known limitations:
š "Do Not Start a New Execution If One Is Already Active" ā Known Limitations
ā
How It's Supposed to Work
When this option is enabled on a Triggered Task, SnapLogic should:
Block any new trigger requests while a previous execution is still running.
Return a HTTP 409 error to the caller if the task is already active.
ā ļø Known Limitation: Pipeline Execute Snap Scenario
The official SnapLogic documentation explicitly calls out the following limitation:
"For Cloud Triggered Tasks in scenarios where multiple pipelines are triggered via the Pipeline Execute Snap, the Do not start another execution checkbox setting is not enforceable."
This means if your task is being invoked (directly or indirectly) through a Pipeline Execute Snap, the concurrency guard will not work reliably.
š§© Why You May See Concurrent Executions (~1 second apart)
A few factors could explain the behavior you observed:
Pipeline Execute Snap
If the trigger chain involves a Pipeline Execute Snap, the setting is explicitly not enforced.
Race condition at the control plane
When multiple requests arrive nearly simultaneously (~1 second apart), the control plane may not have registered the first execution as "active" before the second and third requests are evaluated.
Cloud URL throttling
Cloud Triggered Tasks go through the control plane, which has a default concurrent API limit of 10. The concurrency check and the "do not start" check are separate mechanisms.
Ultra Snaplex behavior
Ultra Tasks/Snaplexes are designed for high-throughput, always-on execution. The "do not start" setting is primarily documented in the context of standard Triggered and Scheduled Tasks ā behavior on an Ultra Snaplex may differ.
š Additional Considerations
Scheduled Tasks also support this setting, and it has a 3-month enforcement limit (after which a second instance can execute regardless).
The setting is under the Debug section of the Triggered Task configuration ā which hints that it may not be production-hardened for all edge cases.
If you need strict mutual exclusion, consider implementing your own locking mechanism (e.g., using a database flag or a SnapLogic pipeline parameter check at the start of the pipeline).
š ļø Recommended Workarounds
- 1.
Implement an application-level lock ā At the start of your pipeline, check a flag in a database or cache (e.g., Redis, a SQL table) and exit early if already running.
- 2.
Use a queue-based approach ā Route trigger requests through a message queue (e.g., SQS, Azure Service Bus) and process them serially.
