Skip to content

Preserved orphaned work: CommandScenario specs for the Unique constraint (do not merge) - #2579

Draft
woksin wants to merge 1 commit into
mainfrom
feature/command-scenario-unique-constraint-specs
Draft

Preserved orphaned work: CommandScenario specs for the Unique constraint (do not merge)#2579
woksin wants to merge 1 commit into
mainfrom
feature/command-scenario-unique-constraint-specs

Conversation

@woksin

@woksin woksin commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Preservation only — do not merge

This is recovered orphaned work, opened as a draft purely so it is discoverable. It is not a live proposal and it is not ready to merge.

The branch was never pushed before now and never had a pull request at any point. It was sitting only in a local checkout.

Why the repository PR template is not used

The template in .github/pull_request_template.md states that "Release notes are generated from this description". This PR must never generate a release note — it ships nothing. The template's ## Added / ## Changed / ## Fixed sections are therefore deliberately omitted rather than left empty.

Why there is no semver label

No major / minor / patch label is applied, and none should be added. A missing label is the correct and intended state: it means no release is cut, which is exactly right for a branch that exists only to preserve history. The verify check will fail because the label is missing. That failure is expected and must not be "fixed".

How far behind main this is

1,148 commits behind main. The merge base is f6eaad58 (2026-04-24).

The diff GitHub renders is enormous and misleading — almost all of it is main moving on, not work this branch did. The branch itself is a single commit touching five files. Do not read the diff. The file list below is the actual deliverable.

What the work is

One commit from 2026-04-24 adding CommandScenario spec coverage for the [Unique] constraint, in both of the shapes it can be applied:

  • [Unique] on an event property — the "a value already exists" rejection path.
  • [Unique] on an event type — the "an event of this type already exists" rejection path.

This is pure test coverage. No production code is touched other than the spec project file.

Files genuinely unique to this branch

Verified individually as absent from origin/main at d9918345:

  • Source/DotNET/Chronicle.Specs/for_CommandScenario_with_UniqueConstraint/given/a_command_that_appends_an_event_of_a_unique_event_type.cs
  • Source/DotNET/Chronicle.Specs/for_CommandScenario_with_UniqueConstraint/given/a_command_that_appends_an_event_with_a_unique_property.cs
  • Source/DotNET/Chronicle.Specs/for_CommandScenario_with_UniqueConstraint/when_executing_command/and_the_unique_event_type_already_exists.cs
  • Source/DotNET/Chronicle.Specs/for_CommandScenario_with_UniqueConstraint/when_executing_command/and_the_unique_property_value_already_exists.cs

The fifth changed file is Source/DotNET/Chronicle.Specs/Chronicle.Specs.csproj, which exists on main and has moved on since.

…nd event type

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@woksin

woksin commented Aug 18, 2026

Copy link
Copy Markdown
Contributor Author

Assessment — is this worth reviving?

Short answer: half of it is genuinely worth harvesting. The other half is already covered. This is a real coverage gap, not just sentiment.

What it appears to do

One commit adding four CommandScenario specs for the Chronicle [Unique] constraint, in both shapes the attribute supports:

  • [Unique] on an event propertyAnEventWithUniqueProperty([property: Unique("unique-name-spec-constraint")] string Name). Execute a command with Name = "Alice" for one event source, then again for a different event source, and assert the second is rejected with validation errors.
  • [Unique] on an event type[Unique("unique-event-type-spec-constraint")] applied to the record itself. Seed one event of that type for an event source, then execute the command and assert rejection.

Pure test coverage. The only non-spec file touched is Chronicle.Specs.csproj.

What has been superseded

The property case. main now has Chronicle.Specs/Commands/for_CommandScenario/when_appending_via_the_event_store/and_the_organization_number_already_exists.cs, built on StartPartnerOnboarding.cs, which declares PartnerOnboardingStarted([property: Unique("UniqueOrganizationNumber", ...)] string OrganizationNumber). It asserts not only that the command fails but that the rejection carries ValidationResultReason.ConstraintViolation, and additionally that nothing was appended for the rejected event source. That is a stronger spec than this branch's ShouldHaveValidationErrors(), so the property half is comprehensively covered and should simply be dropped.

What still applies — and this is the actual finding

The event-type case appears to be uncovered on main. Searching the whole of Source/DotNET on main, the only [Unique] usage in Chronicle.Specs is the property-level one on PartnerOnboardingStarted. There is no spec applying [Unique] to an event type, and no for_CommandScenario_with_UniqueConstraint tree.

That means one of the two shapes of a shipped constraint feature has no CommandScenario-level test. Source/DotNET/Screenplay/Model/UniqueEventConstraintModel.cs exists on main as a distinct model from UniquePropertyConstraintModel.cs, so the two really are separate code paths — this is not a case where covering one covers the other.

CommandScenario itself is alive and well on main and heavily used, so the testing approach here is still the current one.

Caveats

  • 1,148 commits behind main. The specs will not apply as-is: this branch's namespace is Cratis.Arc.Chronicle.for_CommandScenario_with_UniqueConstraint, whereas main has settled on Cratis.Arc.Chronicle.Commands.for_CommandScenario, and the assertion helpers have moved on (main uses _result.IsSuccess.ShouldBeFalse() plus an explicit ValidationResultReason.ConstraintViolation check).
  • I have not run anything. The claim that the event-type case is uncovered is from reading main's tree and grepping for [Unique] usage, not from a coverage report.

Recommendation

Do not merge this branch. Instead, harvest given/a_command_that_appends_an_event_of_a_unique_event_type.cs and when_executing_command/and_the_unique_event_type_already_exists.cs as the design for a new spec written against current main, following the shape of the existing and_the_organization_number_already_exists.cs. Discard the property-half entirely.

Small job, real gain: it closes a genuine hole in constraint coverage. Keep this draft open until that spec exists.

@github-actions

Copy link
Copy Markdown

NuGet packages for this PR, e.g. Cratis.Arc:
https://github.com/cratis/arc/packages/1655206?version=21.19.2-pr2579.5b6a75a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant