fix(bpmn): keep a top-level call activity's fire-and-forget flag through the document PUT - #8082
Merged
Merged
Conversation
Contributor
|
sfmskywalker
force-pushed
the
claude/bpmn-8075-call-options
branch
from
September 12, 2026 18:08
c2f523a to
fefe720
Compare
…ugh the document PUT A call activity's call options (vw:waitForCompletion) live only on its CallProcess work binding, which the bpmnDefinitions document cannot carry, so the document PUT rebuilt every call activity fresh and silently turned a fire-and-forget call into a waiting one. Reuse the stored options for a top-level call activity whose element id and calledElement are unchanged, mirroring how a kept subprocess already carries its own bindings across; a changed calledElement still binds fresh rather than inheriting options authored for a different process. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ImportDocumentAsync's two carry-across helpers each independently looked up SourceXmlCustomPropertyKey and parsed it, so every document PUT read and parsed the stored BPMN source twice. Read and parse it once in ImportDocumentAsync and pass the result to both helpers. Also extends the no-op PUT ETag-stability theory to the top-level-call-activity.bpmn fixture, which was not previously covered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sfmskywalker
force-pushed
the
claude/bpmn-8075-call-options
branch
from
September 12, 2026 18:29
5bd44be to
16f4115
Compare
This was referenced Sep 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #8075. Part of #7909.
Problem
A top-level
callActivityauthored as fire-and-forget (vw:waitForCompletion="false") lost that flag on everyPUT bpmn/definitions/{id}/document. In Bpmn.Interchange 0.2.0 the flag lives only on the reader'sBpmnWorkBinding.CallProcess, and theBpmnDefinitionsdocument cannot carry it. The PUT wrote top-level content without reusing stored bindings, so re-import bound a waiting call. Studio's Performed-by panel PUTs the whole document on any binding edit, so editing an unrelated task was enough to change runtime behaviour silently.Fix: option 2, reuse the stored call options
This mirrors how #8077 reuses kept-subprocess bindings.
ImportDocumentAsyncreads and parses the stored BPMN source once (ReadStoredSource) and passes the result to both reuse helpers. For each top-level call activity in the posted document, it reuses the storedCallProcessbinding, re-keyed to the posted element'sbindingRef, only when:calledElementis unchanged.A changed
calledElement, or a removed or retyped element, binds fresh with the default waiting behaviour, so nothing a client deliberately changed is brought back.CallProcesscarries no other options besidesCalledElementandWaitForCompletion, so nothing is dropped. A posted call activity without abindingRefis skipped rather than refused, since the worst case is the pre-existing default rather than data loss. Without that skip the writer would throw on a null key.There is no contract change: the GET shape, the ETag and the codes are the same, so Studio (elsa-workflows/elsa-studio#1031, #1033) is unaffected.
Tests
top-level-call-activity.bpmn: GET, PUT unchanged, export, and the flag is stillfalse.calledElementbinds fresh.bindingRefis skipped.calledElementcheck, or the null-bindingRefguard each turns its test red.The wiki documents the guarantee next to the "Nested scopes" section.
🤖 Generated with Claude Code