- 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>
- 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>
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>
