Read a command's key without Chronicle

[woksin]

Summary

A read model is loaded by the command's key, and only Chronicle resolved one.

Added

• A command declares the key its read models are loaded by, in an application without Chronicle: a property marked with the data annotations [Key], or an ICanProvideKeyForCommand composing it. The key may be a Guid, int, long, string, or a ConceptAs<T> wrapping one of those (Support injecting read models from non-Chronicle providers into the command pipeline #2303)
• ICanResolveKeyForCommand, for keying commands your own way across an application. It is asked before the rule Arc ships, whichever order the two are discovered in (Support injecting read models from non-Chronicle providers into the command pipeline #2303)
• ARCCHR0008 reports a command marking its key with the data annotations [Key] in an application that uses Chronicle, where it silently resolves nothing (Support injecting read models from non-Chronicle providers into the command pipeline #2303)

Fixed

• Injecting a read model into a command no longer fails as a validation error in an application that has Entity Framework Core or MongoDB but no Chronicle (Support injecting read models from non-Chronicle providers into the command pipeline #2303)

[woksin]

Closes the boundary #2425 shipped and documented: only the Chronicle integration wrote CommandContextKeys.ResolvedKey, so an application with Entity Framework Core or MongoDB and no Chronicle had no key and every read model injected into a command failed as a validation error.

The one thing that makes this safe

Arc reads a command's key only when nothing wrote one. That is load-bearing, so it is verified rather than assumed: EventSourceValuesProvider.Provide() writes ResolvedKey for every command — including the empty key that says the command carried nothing usable — so with Chronicle registered the fallback is unreachable and behavior is unchanged.

Chronicle.Specs/…/for_EventSourceValuesProvider/when_building_command_context_values/with_any_command_at_all.cs asserts exactly that across three command shapes (a key property, no key at all, a key it cannot compose). If a future change ever left the key unwritten for some shape, that spec fails rather than quietly handing key resolution to rules that know nothing of event source ids.

A written key stands as it is, empty included — overturning an integration's "no usable key" verdict by reading the command behind its back would be worse than the gap this closes. Specs cover the written, written-empty, and unwritten cases separately.

Worth your eyes

CommandContextExtensions.GetResolvedKey now takes an optional IServiceProvider and resolves ICommandKeys from it. An extension method reaching into DI is a smell, and I took it deliberately: the alternative was a second ICommandContextValuesProvider writing the same key, and CommandContextValuesBuilder merges provider output last-wins over IInstancesOf<> discovery order — so which of Chronicle's key and Arc's won would have been undefined. Resolving at read time makes precedence explicit in one place. The public no-argument overload is unchanged in signature and now delegates through commandContext.ServiceProvider.

ReadModelUnresolvableDependencyClassifier passes its own serviceProvider, because the CommandContext registered in DI carries none of its own.

Why no inference from a command's shape

The rules are only what the application says out loud. Inferring "the single id-shaped property" would resolve RenameCustomer(Guid CustomerId, …) fine and have no honest answer for MoveItem(Guid CartId, Guid ItemId) — and worse, a command that grew a second identifier later would silently stop resolving a read model injected somewhere else entirely. ICanProvideKeyForCommand covers the composite case explicitly instead.

CommandKeys puts DefaultKeyForCommandResolver last regardless of discovery order, so an application's own rule always decides; a spec asserts both orderings give the same answer.

ARCCHR0008

The failure mode it catches is silent: data annotations [Key] in a Chronicle application compiles, reads correctly, and does nothing — Chronicle finds no key property, invents a fresh event source id, and the read model comes back missing, which surfaces as "the entity does not exist" rather than as a wiring mistake.

It is gated on Cratis.Chronicle.Events.EventSourceId being resolvable in the compilation, and only fires on [Command] types — an EF read model's [Key] is exactly right and is left alone. Both negatives have specs. Chronicle.CodeAnalysis.Specs/Testing/TestProject.cs gains a metadata reference to the data annotations assembly, without which the test sources would not compile.

Verification

Clean dotnet build -c Release from the repository root, all three TFMs: 0 errors, 1 warning — the pre-existing CS0436 in TestApps/Chronicle that reproduces on main.

All 15 spec projects green: Arc.Core 1593 (17 new), Chronicle 563 (3 new), Chronicle.CodeAnalysis 40 (4 new), plus Screenplay 1165, ProxyGenerator 1039, MongoDB 148, EF 300 and the rest unchanged. The new specs were also run isolated by filter, not only as part of their project — a whole-project green hid an ordering bug in #2425 earlier today.

Documentation/verify-markdown.sh passes, 317 links scanned.

Not addressed

ARCCHR0008 catches the confusable attribute on a command. It says nothing about a data annotations [Key] on a command in an application that has no Chronicle, because there it is correct — but it also cannot warn when Chronicle is added to such an application later. Worth considering as part of the MissingWithChronicleAnalyzer story rather than here.

Review

Authored by an agent with no human review. The GetResolvedKey DI decision above is the part I would most want a second opinion on.

[woksin]

The four CANCELLED checks (dotnet-build and the specs / proxy-specs / screenplay-end-to-end jobs that fan out from it) are not failures.

dotnet-build.yml runs on pull_request_target, where github.ref is the base branch — so its concurrency group is shared by every pull request targeting main, and a newer run cancels whatever is in flight. This run was superseded by another branch's.

Not rerunning it: a rerun would cancel that other pull request's in-progress run in turn. A maintainer rerun at merge time settles it.

Everything that does not fan out from dotnet-build passed — CodeQL, all three Analyze jobs, link-verification, markdown-lint, release. Local verification stands in for the rest: clean dotnet build -c Release across all three TFMs with 0 errors, and all 15 spec projects green, with the new specs also run isolated by filter.