Document why activity execution context taint is cleared after commit instead of in the log sink, and refactor commit handler tests to share repeated fixture setup.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Preserve cooperative cancellation during buffered notification flushes and still publish WorkflowStateCommitted after a successful database commit when buffered notification handlers fail.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep buffered commit notification flushes from dropping remaining entries after a handler failure, use the maximum configured transaction timeout for SQL Server commit transactions, and back off distributed bookmark queue retries after lock misses.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Wrap SQL Server EF Core workflow commits in a provider-safe transaction and buffer commit notifications until persistence succeeds. Also preserve dirty activity context state until commit success and make bookmark queue retries resilient to processed-row deletion and transient distributed lock misses.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rebuild local schedules in bounded pages and stagger past-due specific-instant catch-up so orphaned scheduling bookmarks do not flood dispatch during startup.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.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>
- Promote boundary constants to internal in ConfiguredApplicationInstanceNameProvider
- Add InternalsVisibleTo for test assembly to eliminate constant duplication
- Update tests to reference service constants directly
- Replace probabilistic NotEqual assertions with deterministic hex-format assertions
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Backports the opt-in configured application instance name provider from #7734 to release/3.8.0, including 3.8 shell-feature wiring and tests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
CI failed during restore because the centrally pinned CShells preview version
was no longer available from the mapped cshells Feedz source. Local builds did
not reproduce while the preview packages existed in the developer NuGet cache.
Pin the CShells packages to the public 0.0.28 release and allow CShells package
IDs to resolve from NuGet.org in package source mapping, so clean CI restores no
longer depend on unavailable private/feed preview packages.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
In lenient mode (FailOnValidationErrors = false), PublishAsync returns
Succeeded = true while ValidationErrors may still be non-empty. Previously the
publish API endpoints discarded those warnings, so lenient-mode callers got a
200 OK with no indication of the validation issues.
- Publish and Post (save-and-publish) responses now include a ValidationErrors
collection populated with the publish result's validation messages.
- BulkPublish response now includes a Warnings dictionary mapping each
successfully-published definition id to its validation warning messages.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The Publish and BulkPublish API endpoints invoked PublishAsync but ignored
the returned result.Succeeded, so publications that failed due to validation
errors were silently reported as successful. On main, strict publishing is the
default, making this a high-impact correctness issue.
- Publish endpoint: when the publish result indicates failure, surface the
validation errors via AddError and return a 400, mirroring the existing
save-and-publish (Post) endpoint pattern.
- BulkPublish endpoint: add a Failed bucket; definitions whose publication
fails are recorded in Failed instead of Published, and the new bucket is
returned on the response.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This forward-ports the FailOnValidationErrors publish toggle to the 3.8
mainline. It is purely additive and changes no default behavior: publishing
a workflow definition still fails when validation errors are present
(FailOnValidationErrors defaults to true, i.e. strict = opt-out).
Setting FailOnValidationErrors to false — via
WorkflowManagementFeature.UseFailOnValidationErrors(false) or the
ManagementOptions.FailOnValidationErrors option — allows publication to
succeed while surfacing the validation errors as warnings on the publish
result. This enables publishing workflows that intentionally leave required
properties blank (for example, an empty Cron expression used to disable a
trigger).
This is the 3.8 counterpart to #7740, which introduces the same toggle as
opt-in (default false) on the 3.6.x line. References #7738.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
