Claiming was complete, tested, and wired to nothing

[HarryCordewener]

§8.5 closes by saying nothing sets game.is_claimed, so the listing's claimed badge and ArchivePolicy's ceiling-grace (§7.5) have never been exercised. Claiming shipped in #16 and that note still read true, so I went looking for why.

The claim logic was not the problem. It is complete and it has tests. The composition was, and not one of the faults could fail loudly.

What was broken

The site has two compositions of the same objects. mui-crawl builds the crawl loop by hand and passes every collaborator explicitly; the deployed site assembles it through DI. Everything below is true only of the second, which is why every existing test passed.

1. The crawl graph registered no ClaimService. CrawlCycle takes it as an optional parameter — deliberately, because a crawl with no database behind it should do slightly less rather than refuse to run. The site only ever had one because the accounts module happened to register the same type for the dashboard.

2. ClaimService was scoped; the crawl loop that needs it is a singleton BackgroundService.

Cannot consume scoped service 'MUI.Catalog.Persistence.ClaimService'
from singleton 'MUI.Crawler.CrawlCycle'

With scope validation on — what dotnet run does in Development — the container refuses to build and the site does not start with a connection string set. Production leaves validation off, so there it resolved the scoped service from the root and worked. That is the answer to §8.5's note: is_claimed was being set, in Production, by accident, and nowhere else.

3. IClaimStore was registered nowhere at all. Account.razor service-locates it and reads a null as "this site has no database" — so every operator's dashboard was empty on a site holding their claims, and /g/{slug}/claim/check threw on request. In both environments.

4. The on-demand check moved nothing. RequestCheckAsync wrote last_checked_at and a check_requested event. Due-ness comes only from crawl_target.next_probe_at, so no probe ever came of it — while the page told the operator the button dialled a real server. A rate limiter on an action that does not happen is the most convincing possible no-op.

The fix

ClaimService and IClaimStore are stateless over a pooled NpgsqlDataSource, so both become TryAddSingleton, registered by the crawl graph and the accounts graph alike.

IOnDemandProbes brings the game's crawl targets forward — LEAST, so an ask can only ever make a probe sooner, and every target of the game moves because a game is claimed and a target is an address. The crawl loop still does the dialling, under CRAWL DELAY and §7.2's address gate, which is what keeps a button on a page from becoming a way to make us connect to a stranger's server. The button now says what it does: Look sooner.

The test that was missing

CompositionTests resolves the graph Program builds — by calling the same AddMuiSite the deployable calls. It restated the registrations first time round, and a restatement is a second copy that agrees with the first only until somebody edits one of them; the edit that breaks it is precisely the one this file exists to catch. So the graph moved out of Program's top-level statements into SiteComposition, and Program.cs is now the side effects only — connection string, migrations, the log line that says which of the two worlds it is in.

Measured, not asserted. Reverting the three source files to main:

• the original seven tests fail five ways (an earlier revision of this description said seven — that was wrong);
• with the four added since, ten tests fail seven ways.

The three that pass on the parent are the two Production controls and the demo composition, none of which were ever broken.

This is the only kind of test that could have caught any of it. Every part was correct in isolation and had tests proving it. An optional dependency and a service-located one both fail silently when the composition is wrong, and the claim path has one of each.

§8.5's closing note is rewritten to say what is true and to name that hazard, since it generalises past claiming.

Also closed here

• The demo composition had no test. It has one: the claim surfaces are absent rather than present and broken, and the page still admits nothing on it was measured.
• Two NpgsqlAvailabilityStore instances. The web tier registered its own with AddSingleton, so the crawler's TryAdd for IAvailabilityStore was skipped and the concrete type and IReachableHistory pointed at a second one. Harmless on a shared pool, and a direct contradiction of the crawler's own comment that two would be two connection paths answering one question. AddPostgresCatalogue is TryAdd throughout now, and one object answers to all three names.

Passkey sign-in: the #30 report does not reproduce

#30 reported that a JSON POST to a minimal API mapped after UseAntiforgery() is refused with 400 in a slim host, even with .DisableAntiforgery() — which would mean sign-in is broken, and §8.2 leaves no other way in. Measured against the real host: accounts registered, Postgres behind them, migrations applied, ASPNETCORE_ENVIRONMENT=Production.

request	status
POST /account/passkey/assertion-options	200
POST /account/passkey/sign-in (the body passkey.js sends)	401
POST /account/passkey/registration-options	200
POST /account — Razor route, no token — control	400

The control is what makes the rest mean anything: anti-forgery is live in that pipeline and refuses an untokened POST one route over. The 401 is the handler answering — a bogus credential rejected — not the middleware. (The first attempt, skipping the ceremony, returned 500 from SignInManager: "No passkey assertion is underway". Also the handler.)

The mechanism. A minimal API is given anti-forgery metadata only when it binds form data — IFormCollection, IFormFile, [FromForm]. The passkey endpoints bind JSON or a query string, so they carry none and the middleware passes them through. MapRazorComponents puts that metadata on every component route, which is why the control is refused and these are not.

And .DisableAntiforgery() sets RequiresValidation to false, so a 400 that survives it was never anti-forgery's to begin with — that detail in the report is itself the evidence the diagnosis was mis-attributed. Whatever the slim host was returning, it was not this middleware.

PasskeyEndpointTests is added anyway, and not as a formality: sign-in is the only door in the building and no suite opened it — the ones that exercise sign-in are the ones that stub it, and the composition tests stop at the graph. It drives the real routes through AddMuiSite/UseMuiSite with the control alongside, so it fails if anti-forgery ever stops being live and it would catch the reported failure if it ever became real.

Verified

dotnet build MUIndex.slnx -c Release clean, each suite run directly — 860 tests, 0 failed:

suite	total
MUI.Catalog.Tests	217
MUI.Crawl.Tests	136
MUI.Crawler.Tests	82
MUI.Discovery.Tests	183
MUI.Web.Tests	242

Catalog and Crawler against real PostgreSQL via Testcontainers/Podman.

Notes for review

• Branched fresh from main, so it does not contain Owning a game: add what MSSP has no field for, and take your screen back #29. Both touch the registration block in Passkeys.cs; the conflict is adjacent lines and trivial.
• Testcontainers.PostgreSql 4.13.0 → 4.14.0 is the same one-line pickup as Package the deployable, and refuse to build one that carries no schema #26 — main will not restore without it.
• SiteHost.cs from Every slug a game has ever had, beside the games #30 was considered for the harness and does not fit: it composes the same way Program does rather than calling Program's composition, which is the objection this change is answering. When both land, SiteHost should call AddMuiSite too.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2c72d464-8b92-47a6-962c-089b22c9ae99

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[HarryCordewener]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.