intent: step resilience reaches a notify: service task (#7056)

[iliyan-velichkov]

Closes #7056.

The gap

retry: / onError: were accepted on a delegate: service task only, while the generated sender for a notify: step does fail the task on a delivery error — on purpose, and its own comment says so, since the message is that step's whole work. So the send was the one step in a process whose failure had nowhere to go: it took Flowable's default job path and ended as a dead-letter incident.

The failure mode is worse than a lost mail. Ordered where it reads most naturally — before the terminal status write — an SMTP blink leaves a record whose real work completed sitting in its in-progress status with no error message and no failure status, because the incident is on the job, not the record, so nothing in the application can see it. The available workaround, making the send the last step, works and constrains process design for a reason that has nothing to do with the domain: the end of a process becomes the only safe place to put a declared send.

Why v1 was delegate-only, and where the second hook belongs

A runtime reason, not a modelling one — which is why this is issue option (1) and not "relax the check". The conversion that turns an exhausted attempt into the caught INTENT_STEP_FAILED error lives in ResilientClassDelegate, on the flowable:class path; a notify: step is emitted as flowable:delegateExpression="${JavaTask}" and never passes through ClassDelegate.

Flowable 8 exposes no ClassDelegateFactory analogue for that path, so the hook is the overridable factory method itself:

• ResilientActivityBehaviorFactory (now what BpmFlowableConfig configures, still carrying ResilientClassDelegateFactory) overrides createServiceTaskDelegateExpressionActivityBehavior;
• ResilientServiceTaskDelegateExpressionActivityBehavior wraps the single protected handleException the superclass funnels execute / trigger / the future-delegate completion through.

Wrapping rather than re-implementing the catch is the whole design. The superclass propagates a BpmnError the delegate raised itself and applies any flowable:mapException on its own, and only rethrows a plain unmapped failure — which is exactly the predicate ResilientClassDelegate.execute already relies on. So IntentStepResilience is unchanged: same signature, same INTENT_STEP_FAILED / __errorMessage string contracts, same JobRetryCmd finality arithmetic. Both dispatchers (${JavaTask} and ${JSTask}) are covered, which is wider than the DSL lets anyone ask for and deliberately harmless: the conversion fires only on a task carrying the generated boundary, and the parser decides which shapes may ask for one.

Emission

The only addition is the retry cycle on the ${JavaTask} element, written into the extensionElements block the handler field already opens. The <error> definition, the cancelling boundary, its flow and its DI were already shape-agnostic (collectBoundaryErrors walks any step declaring onError), and the {error} setter glue was already generic.

A send keeps its async boundary — the synchronousNodes / completingTransactionNodes walk strips it only from check-gated setters and the decisions on the way to them, and stops at any other step — which is what makes a cycle on it re-run anything at all.

Three refusals, each with its reason in the message

The keys apply to delegate: and notify:. Everywhere else is a parse error, because the declaration would otherwise be authored and inert:

• a setField / setRelationField step — a check-gated status write is emitted without the async boundary on purpose (Intent checks: failure on an async status-set never reaches the user (surfaces only as a background process incident) #7014 / intent: a checks: refusal after Approve parks the process in dead-letter - the message reaches Monitoring, not the user, and only an admin can retry #7063) so its refusal reaches the person who acted; converting it into a routed BpmnError would take that 400 out of the Inbox, and re-attempting a deterministic refusal recovers nothing;
• a call: step or the bare custom.<Step> fallback — not covered; a hand-written handler that wants resilience is bound with delegate:;
• a fan-out send (notify.forEach) — per-row fail-soft by construction, so the step never fails and neither key could fire. Its outcome is observed with outcome: + event: { onNotifyFailed: <Entity> } (intent: a notify delivery failure is invisible - the transition succeeds, the mail never leaves, nobody is told #7023).

The generated sender's exception message also gained its cause (... process: <cause>): that string is verbatim what an onError route records through {error}, and a fixed sentence would put "the mail failed" on the record and nothing an operator can act on.

Coverage

Every new negative case was written red-first.

Layer	Test
parser	StepResilienceIntentTest — the send parses; the setter / bare / fan-out refusals (4 fail without the change)
emission	ResilienceBpmnTest — the cycle rides the send's own element after its handler field, its boundary + DI, and both byte-identical pins still hold
BPMN contract	IntentResilienceBpmnContractTest — the new delegate-expression shape through the real BpmnXMLConverter
live engine	ResilientServiceTaskDelegateExpressionEngineTest — exhausted cycle routes the FINAL attempt and never dead-letters; recovery converts nothing; and a delegate raising its own BpmnError still reaches its own boundary (the must-not-break case the wrapper is responsible for)
IT, emission + parse	IntentEngineIT
IT, runtime	IntentEmissionCoverageIT — a send mid-process whose exhausted retry routes onto the record and lets the flow carry on to the hold
IT, sample journey	sample-intent-resilience + IntentResilienceSampleIT — a third tenant title exercising the issue's own reproducer, through the browser IDE

Without the hook the doomed instance never finishes (it dead-letters) — that timeout is the red-first proof.

The sample

tests/tests-integrations/src/main/resources/sample-intent-resilience gains a send step mid-process, deliberately not last, reached by a tenant titled notify; the sample has no SMTP, so the delivery always fails. It ends Failed carrying Failed to send the notifyOwner mail of the TenantProvisioning process: … — which can only happen via the boundary route, since a dead-lettered send would leave it in Requested. The README's walk-through covers it, and the existing two tenants are unaffected.

Docs

• dirigible.io — docs(intent): step resilience applies to a notify service task too dirigible-io/dirigible-io.github.io#237 (merged).
• Specification — proposal: a step's failure is part of the model — retry, onError and {error}, on a delegate and on a send IntentFile/intent-specification#71 and spec: a step's failure is part of the model — retry, onError and {error} IntentFile/intentfile.github.io#54, open for review. Step resilience turned out to be unspecified upstream entirely (intent: declarative step resilience - retry, error routing and step data in processes: #6762 never landed a proposal), so the proposal specifies the whole construct rather than only the widening.

🤖 Generated with Claude Code