elsa-core/test/integration/Elsa.Workflows.IntegrationTests
Sipke Schoorstra 749b6491fc
fix(core): a throwing FaultSignal handler must not escape the middleware (#7924)
* fix(core): a throwing FaultSignal handler must not escape the middleware (#7911)

The signal is sent from inside the catch whose whole job is to stop exceptions
escaping the activity pipeline. A handler that threw went straight through it:
no incident, no strategy, and the original fault lost along with it.

The send is now guarded. A handler that throws is treated as not having handled
the fault, so the incident strategy runs exactly as it would with no handler
present. That is the conservative direction: a handler that failed part way
through may have left the faulted activity in any state, and an incident is a
better answer than silence. Its exception is logged at error level, because a
broken fault handler is a defect in its own right rather than a workflow
outcome.

Covered both ways, since a handler that already claimed the fault before
throwing is the case that could plausibly have been mistaken for success.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(core): let cancellation from a fault handler propagate

The handler guard caught OperationCanceledException along with everything else,
so a cancellation raised while an ancestor was being offered a fault was logged
as a broken handler and handed to the incident strategy. A deliberately
cancelled run reported itself faulted.

Cancellation is excluded now, matching how this repository already keeps the two
apart: the workflow-level exception middleware cancels and rethrows before its
general catch, and WorkflowRunner declines to record cancellation as the
workflow's exception.

Caught by review on #7924.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(core): pin that a handled fault stays in the execution log

The justification for dropping the incident is that the journal keeps the
evidence. That was asserted in several places and guarded nowhere.

It holds because ExecutionLogMiddleware writes the Faulted entry from a catch
that rethrows, and it is registered inside ExceptionHandlingMiddleware, so the
entry lands before the fault is ever offered to an ancestor. Swapping those two
registrations would make a handled failure disappear from the record with
nothing failing, which is what this test now prevents.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 05:34:19 +02:00
..
Activities test: refactor with WorkflowTestFixture (#7394) 2026-04-15 14:04:49 +02:00
Api/Bookmarks [codex] Harden initial security remediation slice (#7495) 2026-05-22 00:45:47 +02:00
Core Merge remote-tracking branch 'origin/patch/3.5.4' into release/3.6.0 2025-12-29 20:00:03 +01:00
Evaluation Add Elsa Script DSL (#7076) 2025-11-25 19:57:50 +01:00
GracefulShutdown fix: do not resume interrupted workflows that are already finished (#7435) 2026-05-18 21:19:23 +02:00
Scenarios fix(core): a throwing FaultSignal handler must not escape the middleware (#7924) 2026-08-12 05:34:19 +02:00
Security [codex] Harden C# expression host-code execution (#7519) 2026-05-21 00:50:25 +02:00
Serialization Add named WithVariable overload (#7701) 2026-06-08 10:42:59 +02:00
SharedHelpers Refactor commit strategy resolution for improved clarity and efficiency; remove unused example files and add a new CommitTracker helper for testing. 2025-12-16 08:01:49 -05:00
Elsa.Workflows.IntegrationTests.csproj Harden Python expression execution (#7507) 2026-05-20 14:19:47 +02:00
Elsa.Workflows.IntegrationTests.csproj.DotSettings Fix WorkflowExecutionContext bug (#4919) 2024-02-09 19:37:37 +01:00
Usings.cs Refactor Workflow Runtimes (#5444) 2024-06-10 19:36:51 +02:00