* feat(bpmn): host-side applier for the Bpmn.Semantics port
Translates the interpreter's three host commands onto ActivityExecutionContext
and feeds its four entry points, plus the minimum BpmnProcess container needed
to exercise them end to end through IWorkflowRunner.
StartWork schedules the bound activity, CancelWorkSubtree calls the public
CancelActivityAsync extension (already recursive), and SignalEnclosingScope
sends a BpmnScopeSignal up the ancestor chain. OnWorkFaulted rides the
FaultSignal seam: it asks the interpreter what BPMN made of the fault and calls
StopPropagation only on a Caught disposition, leaving a Propagated one strictly
alone so an enclosing scope or the incident strategy takes it.
A unit of work is keyed on the child ActivityExecutionContext.Id, recorded in
the scope's own persisted ledger, never on Tag: the completion-callback dispatch
rewrites the receiving context's Tag, so a nested scope wears a different tag
than its parent remembers it by. Interpreter correlation travels on the child's
context rather than on the shared activity instance.
Evaluations go through one queue per workflow instance, so a scope signalled
mid-apply is drained after the command list rather than re-entering the
interpreter. Commands are applied in the order returned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(bpmn): cover the teardown refusal path
Adds a focused unit test that drives BpmnWorkTeardown.CancelSubtreeAsync
into the NotSupportedException branch by constructing a real context tree
with a scheduled-but-not-invoked descendant, so a regression that silently
drops the detection is caught. Also records why BpmnWorkLedger's
append-only, handle-keyed Records list cannot strand a context on a
duplicate StartWork for a live (BindingRef, IterationId) slot, a case the
port's own guarantee makes unreachable from this applier.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(bpmn): keep a refused teardown from stranding ledger state
A subtree cancellation refused with NotSupportedException is absorbed
into an incident under ContinueWithIncidentsStrategy rather than
crashing, so the end-of-command ledger save was being skipped and the
persisted ledger kept claiming work BPMN had just torn down. Save the
ledger removal before the possible throw instead of after, so a later
completion callback for the stranded activity finds no live record and
is discarded instead of being fed to the interpreter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* test(bpmn): guard against Elsa.Bpmn* reimplementing Bpmn.* library types
Adds a reflection-based architecture test asserting no type under Elsa.Bpmn
or Elsa.Bpmn.Interchange shares a type name with Bpmn.Model/Bpmn.Semantics
(and Bpmn.Interchange for the interchange assembly), plus a positive check
that both assemblies still depend on their respective library packages -
closing the gap that let elsa-foundation grow a parallel BpmnElement/BpmnGraph
semantics core undetected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(bpmn): move the library-duplication guard to the interchange test project
Elsa.Bpmn.UnitTests referencing Elsa.Bpmn.Interchange (plus three
redundant PackageReferences already flowing transitively) inverted the
layering the guard exists to protect. Elsa.Bpmn.Interchange.UnitTests
already sees both assemblies transitively with no new references, so
the guard moves there unchanged apart from namespace and doc. Also
drops the silent null-forgive on Assembly.GetName().Name in favor of
an explained fallback.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(bpmn): drop the dependency-direction assertions the compiler already enforces
Mutation testing showed AssertDependsOnPackage and the two positive facts using
it can never go red: any state that would trip them fails the test project's
build first (CS0234), because the guard's own typeof bindings already require
the Bpmn.* packages. Delete the decorative facts and the now-unused helper,
and document that the typeof bindings are load-bearing on purpose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(bpmn): prove the duplication detector actually detects
Split AssertNoTypeNameCollisions into a thin assertion wrapper around a
new FindTypeNameCollisions helper, and add a fact that points the
detector at the test assembly (which carries a deliberately colliding
BpmnGraph fixture) so CI sees the guard fail as well as pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Adds the valence-works/bpmn package feed and pins Bpmn.Model,
Bpmn.Semantics and Bpmn.Interchange at 0.1.1-preview.19, then wires
two new module projects consuming those libraries without
reimplementing anything they provide (D12): Elsa.Bpmn for BPMN
execution and Elsa.Bpmn.Interchange for XML import/export, kept as a
separate package so hosts that only execute BPMN don't take the XML
reader. Both are marked IsPackable=false until the Bpmn.* packages
are published to nuget.org. Test projects are added for both, unit
and integration, and all four are wired into Elsa.sln so PR CI
discovers and runs them. This unblocks #7925 and the rest of the
BPMN runtime work in #7909.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* 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>
* fix(core): a fault a container claimed is not an incident (#7911)
RecoverFromFault reset the counts and the status but left behind the two other
things Fault recorded: the ActivityIncident and the exception. So a container
that successfully handled a child's fault still left the workflow carrying an
incident.
That is not cosmetic. Code reads a non-empty WorkflowExecutionContext.Incidents
as "this workflow failed" without looking further; HttpWorkflowsMiddleware is
one, and it hands the caller a fault response. A workflow whose container caught
the error and finished normally was reported to its caller as failed.
RecoverFromFault is now the inverse of Fault: it removes the incident Fault
appended, matched on this activity's node id and most recent first so an
activity that faults, recovers and faults again keeps the incident that was
never recovered, and it clears the recorded exception so the activity does not
sit in Running carrying one.
The execution log still records the failure, so nothing is hidden from anyone
reading the journal. Two integration assertions that encoded the old behaviour
are updated; they were written from the reasoning this change corrects.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(core): tie an incident to the execution that raised it, not its node
Recovery matched the incident to remove on ActivityNodeId, which identifies the
static workflow node rather than an execution of it. A node inside a loop,
retried, or run concurrently raises one incident per execution, all under the
same node id, so recovering one execution could remove another's incident and
leave its own behind.
ActivityIncident now carries the ActivityInstanceId of the execution that raised
it, and recovery matches on that. Within a single execution the most recent is
still taken, so fault, recover, fault again keeps the incident that was never
recovered. The property is optional: an incident recorded against the workflow
itself has no execution, and so do incidents persisted before this existed.
Caught by review on #7923.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(api-client): mirror ActivityInstanceId on the client incident model
The server model gained the property in the previous commit and the API client
carries a hand-maintained copy of it. Left alone, a client deserializing an
incident would silently drop the only field that says which execution raised it.
Also records two consequences of recovery that were implicit: it relies on the
incident collection preserving insertion order to pick an execution's newest
incident, which holds only because the collection is list-backed; and clearing
the exception also clears it from the activity's execution record, which is
intended for the same reason the incident goes, with the journal keeping the
evidence either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Review caught that the contract advertised something that cannot work. It
offered handlers three ways to terminalize the faulted activity - cancel,
complete, or reschedule - but CompleteActivityAsync returns immediately unless
the activity is Running, and throughout the handler it is still Faulted, since
recovery runs only after the handler returns. Completing inline did nothing at
all, silently, leaving the child Running.
Measured, same container, handler completing the faulted child:
inline complete -> child Running, no output, Running/Suspended
TransitionTo(Running), complete -> child Completed, "after", Finished/Finished
So a supported path exists; it just needed writing down. Document it on
FaultSignal, note that it is not licence to call RecoverFromFault (which also
rewrites the fault counts), and note that cancelling and rescheduling need no
equivalent step. Cover it with an integration test asserting that completing the
child with a substitute result fires the container's completion callback and
resumes its sequencing.
Refs #7911
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Review raised that TrySendSignalAsync delivers to the faulting activity before
walking ancestors, so an activity that throws and also handles FaultSignal can
claim its own fault and suppress the incident strategy.
That is real, but it is the channel's existing dispatch, which #7911 chose
deliberately over a variant of it, and SignalContext.IsSelf exists so handlers
can discriminate. It also grants no capability: an activity that catches its own
exception never faults at all, ending Finished/Finished with zero incidents,
which is a cleaner suppression than self-handling (incident still recorded,
activity left Running, workflow suspended).
So dispatch is unchanged. What was missing is that none of this was written
down: the contract describes the handler as an enclosing container and never
mentioned self-receipt. Document it on FaultSignal, including how a handler
that wants ancestors-only semantics opts out, and add a test so the behavior is
pinned rather than incidental.
Refs #7911
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A container activity had no way to learn that one of its children faulted.
ExceptionHandlingMiddleware caught the exception, called context.Fault(e) and
handed off to the workflow-global IIncidentStrategy; the container's completion
callback never fired, because the child never completed.
Add a seam on the ancestor-bubbling signal channel that already exists:
- FaultSignal(Exception, ActivityExecutionContext), beside CancelSignal. Its XML
doc carries the contract, including why a handler must not call
RecoverFromFault and why the CompleteActivityAsync sweep is a backstop rather
than the mechanism.
- An internal bool-returning TrySendSignalAsync, since SignalContext
.StopPropagationRequested is internal and SendSignalAsync reported nothing.
SendSignalAsync keeps its public signature and delegates to it.
- ExceptionHandlingMiddleware sends the signal after faulting and, when an
ancestor stops propagation, calls RecoverFromFault once and returns instead of
raising an incident.
RecoverFromFault now transitions to Running only when the activity is still
Faulted. It is called after the handler runs, so the unconditional transition
would otherwise undo a handler that cancelled or completed the faulted child.
The counts are still reset unconditionally, and the one pre-existing caller is
unaffected.
Behavior is unchanged when nobody handles the signal: verified by running the
new unhandled-fault theory against the pre-change middleware, and by
IncidentStrategyTests and Primitives/FaultTests passing unmodified.
Refs #7911
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Configured stable application instance names that exceed the Azure Service Bus transport entity limit are now shortened deterministically instead of failing startup. The same configured value resolves to the same shortened name across restarts, preserving stable per-instance transport identity while supporting normal Kubernetes pod names.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Make validation constants internal and expose via InternalsVisibleTo so tests reference single source of truth
- Add empty-string guard to IsValidConfiguredInstanceName to prevent IndexOutOfRangeException
- Add ClusteringFeature_UsesConfiguredInstanceNameProvider test for Features.ClusteringFeature to match existing ShellFeatures coverage
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Forward-port the opt-in stable application instance name support from PR #7734 so clustered deployments can reuse per-instance transport entities across restarts while preserving random names by default.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Implement Weaver AI Copilot core
* Address Greptile review feedback
* Address Greptile persistence feedback
* Address Greptile orchestration feedback
* Address Greptile tool isolation feedback
* Wire chat audit events
* Stream chat events over SSE
* Use server identity for AI endpoints
* Validate AI proposal persistence
* Isolate AI audit failures
* Enforce AI tool lookup scope
* Support AI tool result continuations
* Handle AI chat reconnects safely
* Tighten AI context and reconnect behavior
* Guard AI conversation and persistence setup
* Persist AI tool-loop progress
* Tighten AI tool registry and reconnect cleanup
* Handle AI preparation failures cleanly
* Order AI tool messages after assistant turns
* Initialize AI provider sessions
* Align AI context capabilities
* Prevent completed AI reconnect replay
* Enforce AI conversation ownership
* Default AI proposal creation time
* Persist AI session and retention defaults
* Allow AI context provider overrides
* Scope AI tool results per turn
* Apply AI provider configuration
* Scope AI proposal reads
* Avoid duplicate AI tool continuations
* Resolve AI tool registry scopes
* Tighten AI reconnect cleanup
* Honor default AI proposal tools
* Pass AI provider session to turns
* Close AI observability gaps
* Fix AI capabilities options alias
* Harden AI orchestration lifetimes
* Track actual AI reconnect conversation
* Address AI audit and context review findings
* Fix AI reconnect and persistence capabilities
* Handle AI session startup failures
* Tighten AI orchestration review gaps
* Warn on placeholder AI context
* Filter disabled AI provider tools
* Add durable AI conversation persistence
* Fix AI orchestrator persistence lifetime
* Handle failed AI reconnect edge cases
* Harden AI reconnect failure handling
* Address AI reconnect and cleanup review gaps
* Tighten AI audit and cleanup persistence
* Keep expired AI cleanup best effort
* Tighten AI tool lookup and cleanup fallback
* Handle AI provider and tenant edge cases
* Tighten AI proposal and agent authorization
* Address AI tool scope cleanup review
* Close remaining AI greptile findings
* Harden AI stores and tool defaults
* Harden AI conversation persistence edge cases
* Cover AI proposal and tool visibility guards
* Fix AI capabilities and audit batch resilience
* Fix AI conversation truncation for unicode
* Resolve remaining AI persistence review nits
* Wire AI conversation persistence option
* Address AI audit and proposal style review
* Fix AI stream truncation surrogate handling
* Address AI context and cleanup review
* Preserve AI titles and tenant tool defaults
* Guard AI conversation user ownership
* Align in-memory AI conversation ownership
* Fix expired AI conversation cleanup tracking
* Harden AI proposal persistence retry
* Tighten AI proposal reads and cleanup SQL
* Harden AI reconnect and provider defaults
* Optimize AI tool listing and message trimming
* Preserve AI conversation timestamps
* Address final AI persistence review nits
* Normalize AI acronym casing
* Address Copilot AI review comments
* Normalize default tenant handling for AI stores
* Harden AI registry and message truncation
* Make AI tool filtering explicit
* Align AI contracts with implementation
* Align remaining AI review contracts
* address greptile ai persistence feedback
* Address Copilot AI persistence feedback
* Address Copilot AI host feedback
* Order persisted AI conversation messages
* Address Copilot chat and cleanup feedback
* Release unused AI reconnect reservations
* Address Copilot AI review feedback
* Address Copilot tool and conversation feedback
* Address Copilot governance feedback
* Address Copilot tool test feedback
* Address AI review follow-ups
* Address Copilot AI follow-ups
* Clean up AI persistence tests
* Address IAITool disposal review
* Address AI integration review follow-ups
* Address AI chat persistence review
* Address AI registry and truncation review
* Enable read-only AI tools by default
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Add dashboard API foundation
Merge dashboard API foundation into dashboard-v2
* Harden dashboard API provider
Documents the dashboard API contract, adds provider behavior tests, and degrades diagnostics capability states independently.
