Spec 017 phase 4: tranche 2a compile repairs — 234 blocks build, ≤ 60 met, #4443 and #4444 filed

[iancooper]

Summary

Phase 4 of spec 017 repairs the 22 tranche 2a pages, the Outbox and Inbox pages with one hard block each. Every page is now whole: each C# block on it either builds against Brighter 10.7.0, or is listed with its reason in tasks.md § Blocks that stay FAILED. The only listed block is ReplayOnSeenReference.md #1. It uses CausationId, which exists only on Brighter master (P2-2).

This PR changes the published site, so it needs your sign-off to merge. After the merge, may I delete the head ref spec/017-phase4?

Defects found by running the blocks, repaired everywhere they occur

git diff --name-only origin/master..HEAD -- contents lists 28 pages:

• 21 of the 22 tranche pages;
• 2 pages changed by recurrence repairs;
• 5 pages changed on your rulings: four for #4335 and SweeperCircuitBreaking.md.

Inbox pages

• InMemoryInbox.md said entries are kept until the process restarts. In fact an entry expires 5 minutes after it is written, and past EntryLimit the store compacts. The page also showed a global Warn configuration beside an attribute whose default of Throw wins over it. I ran both claims with controls, and the page now describes the actual behaviour.
• Inbox configuration blocks had three compile errors:
  • a ConfigureServices lambda that was never opened, on 13 lines across 8 pages;
  • opt. used inside a lambda whose parameter is options;
  • a ; inside an object initialiser.
• [UseInboxAsync] was placed on a class, where it is not valid.
• One outbox handler called await Post(…, cancellationToken), but Post is synchronous and takes no cancellation token.

Outbox pages

• The EF Core outbox pages, DapperOutbox.md and DynamoOutbox.md showed methods without their class. They are now shown whole.

Distributed lock pages

• All six pages now compile and needed no content change. On MSSQL, MySQL and Postgres in Docker I confirmed that a lock is released when its holder's session dies.

Azure Blob archive and sweeper circuit breaking

• AzureBlobArchiveProvider.md had eight defects in its one block. For example:

  • AzCliCredential does not exist; the class is AzureCliCredential.
  • The options type has no parameterless constructor.
  • BlobContainerUri is a Uri, not a string.
  • BatchSize is actually ArchiveBatchSize.

  The block is rewritten against 10.7.0. The page gains an options table and the two packages the provider does not bring in.

• UsingSweeperCircuitBreaking.md:

  • The custom breaker used a CircuitBreakerState type that nothing declares. It also used a plain Dictionary, which threw "Collection was modified" when trips and cooldowns ran concurrently.
  • The "distributed" breaker could never report its tripped topics, because IDistributedCache cannot list its keys. It is now a complete breaker on a Redis sorted set, run against Redis with two connections.

• SweeperCircuitBreaking.md, repaired on your ruling:

  • The page set the sweep interval through OutboxSweeperOptions.SweepInterval, which does not exist. The real setting is UseOutboxSweeper(o => o.TimerInterval = …).
  • The cooldown formula was one sweep short. A tripped topic is retried after (CooldownCount + 1) × TimerInterval. I confirmed this with a real sweeper and a failing producer.
  • The page claimed circuit breaking works with every Outbox. The DynamoDB and Spanner Outboxes ignore tripped topics; I ran both against DynamoDB Local and the Spanner emulator, with SQLite and MongoDB as controls. The page now has a table of which Outboxes honour a trip.
  • The page also called UseMongoDbOutbox, which does not exist.
  • The page contradicted itself about explicit clearing. In fact ClearOutbox and ClearOutboxAsync send messages for tripped topics. A failed ClearOutboxAsync trips the topic; a failed ClearOutbox does not.

Upstream issues, handled on your rulings:

• NoExternalBus() silently discards InboxConfiguration, so a consumer-only process gets no Inbox Brighter#4335: a global InboxConfiguration is ignored unless the application calls AddProducers. It is fixed on master but not released. BrighterInboxSupport.md states it with a workaround, and the nine inbox pages link to that.
• DynamoDbOutbox ignores trippedTopics, so the sweeper's circuit breaker has no effect Brighter#4443 (DynamoDB) and #4444 (Spanner), filed in this phase: both Outboxes ignore tripped topics. SweeperCircuitBreaking.md links to both.

Every block that asserts behaviour was run against the released packages, with a control. The tables are in tasks.md § Phase 4 as executed.

Gates

#	Gate	Result
1	linkcheck	165 files, 0 broken
2	pagelint	0 errors; warnings 658 → 616: 36 fewer on the tranche pages, which was the predicted floor, and 6 fewer on two pages outside the tranche
3/4/7	shape / redirects / --verify	unchanged: 161 / 77 / 161
5	versioncheck	0 stale of 18, across 5 pages
6	optioncheck	0 mismatches, 59 tables, 519 rows
8	symbolcheck	0 findings, 22 entries, 3 silenced
9	blockcheck	983: 234 BUILT (was 189; predicted 204–230), 733 FAILED, 16 SKIPPED; 35 scaffold units, 0 violations; 542 reference assemblies

Gate 9 is 4 above the ceiling. Five blocks moved on pages outside the tranche: two by recurrence and three on your ruling. One block the ceiling counted, TickerQScheduler.md #2, still fails because of the statements wrapper. attr_mismatch.py holds at 7.

The pin grows by three packages, to 98: Npgsql.EntityFrameworkCore.PostgreSQL, TickerQ.Dashboard and TickerQ.EntityFrameworkCore. I measured it on its own first.

The AC2 diff against c7329bb prints 135 lines:

• 134 are FAILED -> BUILT: 89 from phases 2 and 3, and this phase's 45.
• The 135th is SchedulingAMessage.md Update documentation #10, which § Splits already records.

Pages with nothing BUILT: 74 → 57. The ≤ 60 target is met.

Outside contents/, the PR changes:

• tools/README.md: rows 2 and 9, and a paragraph for phase 4;
• the blockcheck baseline, refs.csproj and pages.tsv (36 → 53 pages mapped);
• 5 new scaffold units and 4 changed ones;
• spec/017-compile_repairs/tasks.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_016Am29wrQUS81NVh8dUyNuy