Run the bounded fingerprint sweep smoke test on Railway test

[Erilla]

Question

Task 7 Step 3 of the achievement-fingerprint discovery plan was never carried out. The commit docs: record fingerprint sweep validation (6c5a1c4) records the Railway variables the worker now needs, not a run result, so no fingerprint sweep has executed against a live root in a deployed environment. The feature merged to main in #29 on that basis.

The step, unchanged from the plan:

Deploy to Railway test with only the already-provisioned worker credentials. Submit one known eligible public root, confirm the worker reserves its cap, completes within it, and the public page/API shows a normal undifferentiated list.

Record only root key, run outcome, request count, duration, snapshot state, and limitation class — no raw upstream data and no secrets. Ictinus is the root the measurement prototype used: 393 requests in 134s, three matches at 49.6–52.5%.

Worth confirming in the same pass, since neither has run outside tests:

• The pg-boss exclusive-policy migration upgrading a queue that already carries deployed jobs.
• MAINTAINER_ALERT_WEBHOOK_URL delivery, if a sink is configured.

Requires a deploy and the real Blizzard credentials, so it needs a human.

[Erilla]

Run result

Step 3 has now been carried out on Railway test. Two sweeps were executed against live roots, and the second one is the one this step asked for: a sweep that reserves its cap and finishes inside it.

Environment under test. main @ 6108d2f, worker deploy 83219216 (SUCCESS, worker_ready 21:49:15 BST), web /health and /ready both 200. BLIZZARD_SWEEP_REQUEST_CAP=1100, DISCOVERY_REQUEST_CAP=12. Times below are UTC, as logged.

Sweep A — cap exhausted

Root	eu/draenor/Shurkle
Cap at the time	300
Requests used	300 of 300
Duration	91,267 ms
Snapshot	partial, fingerprint_sweep_capped, 13 characters

Run while the cap was still 300. Its only value here is that it shows the cap is a real ceiling, not advisory.

Sweep B — cap reserved, sweep finished inside it

Root	eu/draenor/Shurkvoker (Evoker 90, guild Rancour, 393 roster members)
Run id	547a85c8-7b91-42c6-a57d-9d39eec0cb60
Queued / started / completed	22:13:40.753 / 22:13:40.838 / 22:15:36.904
Duration	116,090 ms total, 113,904 ms in the fingerprint stage
Admission wait	none — reserved on first attempt
Requests reserved	1,100
Requests used	396 — roughly 288 ms per request
Snapshot	partial, privacy_hidden, 13 characters

The sweep itself was exhaustive: every one of the 393 roster members was fingerprinted and the run stopped because it had run out of candidates, not out of budget. fingerprint_sweep_capped was correctly absent.

Public surface

GET /api/v1/characters/eu/draenor/shurkvoker returns exactly five snapshot fields — id, state, refreshedAt, characterCount, characters — and no limitation code. The rendered page carries the 13 names and the word Partial, and zero occurrences of fingerprint, achievement, or privacy. The list is undifferentiated: nothing distinguishes a Raider.IO-derived link from a fingerprint-derived one.

pg-boss exclusive-policy migration

Verified against a queue that already carried deployed jobs, which was the open question.

• pgboss.queue: both discover-character and fingerprint-admission are policy=exclusive, with updated_on of 21:49:15.390 and 21:49:15.408 — the migration changed them during that boot, not at creation.
• pgboss.job at the time of that boot already held 5 completed discover-character rows with policy=standard. Those rows are untouched; the 8 jobs enqueued since are exclusive.
• No rows were moved to cancelled, so the de-duplication branch found nothing to collapse and did no collateral damage.

MAINTAINER_ALERT_WEBHOOK_URL

Not set on test, so there was no sink to deliver to. Untested, and still untested in any deployed environment.

One thing this run did not establish

No complete snapshot has yet been published through the fingerprint path. The reason is not the cap — 396 of 1,100 — but that the Raider.IO stage records privacy_hidden for this root, and packages/domain/src/discovery.ts:349 degrades the snapshot to partial on that basis before the sweep is even considered. That is the documented behaviour: hidden ownership means Raider.IO contributes no links, so any character outside the guild roster stays invisible, and partial is honest about it.

It does mean an exhaustive 393-member sweep still surfaces as Partial to the user, permanently. Recorded on #41, which is where the semantics should be decided.

fingerprint_sweep_request_events holds 696 rows, oldest 21:33:53 — all still inside the rolling hour, so the prune added in #29 has had nothing to delete yet and remains unexercised against real data.

Closing: the step as written is done.