UrlResolver PR 893: relay preference accounting blocked on load-shape mismatch

RE-VERIFY before resuming. This snapshot was checked at 2026-07-29T13:18:33Z. Re-run gh pr view 893 --repo CodexCoder21Organization/UrlResolver --json state,mergeStateStatus,mergeable,statusCheckRollup,mergedAt,headRefOid,url, then fetch the branch and confirm both local and remote heads. The recorded live state was OPEN, unmerged, mergeable but BLOCKED at 3dd16c6b5c11e28c4cd2c11e92fe2cef3f791e98; exact-head buildtest run fc6994d1 was still in progress after both required reproducers had failed.

Mission

Rebase https://github.com/CodexCoder21Organization/UrlResolver/pull/893 onto current main, use a free resolver coordinate, verify the fixed preference and starvation bars without changing any timeout, budget, attempt cap, or iteration count, get the complete buildtest suite green, and leave the PR review-ready. Do not merge, deploy, or publish.

What was done and found

• Work used the required fresh clone at workspace/codex-pr893/. The original head 1d99c1135e0646a6dded5710d602f57d1e417f40 was already based on current main 086927a2c8be309c61b2a5bff551e278ece6dec1. A forced replay produced content-identical head 1479e570ad5d920d40d2c1971d6cabd077a7a3b1 with no content conflicts. Coordinate 0.0.710 was free.
• The content-identical isolated run 150b0a7e failed the preferred-selection reproducer with 6 wrong winners out of 18 and the lower-tier starvation reproducer with 10 misses out of 18. The third named regression test passed.
• Three code-only corrections were tried. None changed a test, timeout, pass budget, attempt cap, or iteration count:
  • 179bf0463c34024b0af6f486362dead615dd52a0, coordinate 0.0.711, reserved one full lower opportunity. Run 83fe44c5: preference 11/18 wrong; starvation 10/18 missing.
  • 600bc239ef49ea6228af9567e0b797a443d7bc21, coordinate 0.0.712, serialized registration attempts to match synchronized RelayService.registerWithRelay. Run 9a33b41d: preference 6/18 wrong; starvation 10/18 missing.
  • 3dd16c6b5c11e28c4cd2c11e92fe2cef3f791e98, coordinate 0.0.713, fixed cancellation accounting when a queued callable is cancelled before it starts. Run fc6994d1: preference 5/18 wrong; starvation 10/18 missing.
• The cancellation bug is real: the quiescence latch was decremented only in the callable's finally, which cannot execute if cancellation wins before the callable starts. The atomic queued/running/done lifecycle fixes that narrow accounting error, but the acceptance failures prove it is not the full cause.
• Remaining starvation failures show only about 2-4 accepts at each dead preferred endpoint and finish near the 10-second pass limit; successes show about 6-8 accepts and reach the lower relay. The remaining pass is being used before the lower registration can run.
• A fresh read-only UrlProtocol inspection did not establish an upstream fix. Resolver pins protocol 0.0.409; the connectToRelay interruption path is identical to current protocol main. UrlResolver PR https://github.com/CodexCoder21Organization/UrlResolver/pull/892 moves the suite to protocol 0.0.419, but it is a large overlapping change and there is no evidence yet that it fixes this starvation case.
• Local targeted tests were skipped because the shared eight-core host remained heavily loaded and the task explicitly permits relying on isolated buildtest in this condition. Exact-head buildtest runs compiled the code and exercised the reproducers.

Blocking contradiction

The written fixed criterion says “six concurrent registrations across three rounds.” The checked-in preference reproducer implements that shape with three sequential rounds of six threads. The checked-in starvation reproducer does not: it creates all 18 threads with flatMap, starts all of them, and releases all 18 through one gate.

The buildtest runner also overlaps tests. In run fc6994d1, the six-way preference test began while the 18-way starvation test was active, producing 24 public-path scenarios at once. Four of the first six preference scenarios failed during that overlap; only one of the later twelve failed after starvation ended.

Changing the starvation harness to three sequential six-way rounds would match the written criterion and keep 18 total outcomes, but it would reduce peak concurrency from 18 to 6. The task explicitly forbids weakening tests. Keeping the current all-18-at-once harness means the checked-in gate does not match the pre-registered load shape. Work stopped as required instead of silently choosing one.

Relevant references

• PR: https://github.com/CodexCoder21Organization/UrlResolver/pull/893
• Current remote branch: https://github.com/CodexCoder21Organization/UrlResolver/tree/fix/relay-preference-attempt-accounting
• Current commit: https://github.com/CodexCoder21Organization/UrlResolver/commit/3dd16c6b5c11e28c4cd2c11e92fe2cef3f791e98
• Content-identical rebase run: https://buildtest.kotlin.build/run?id=150b0a7e
• One-lower-slot run: https://buildtest.kotlin.build/run?id=83fe44c5
• Serialized-attempt run: https://buildtest.kotlin.build/run?id=9a33b41d
• Queued-cancellation run: https://buildtest.kotlin.build/run?id=fc6994d1
• Tool issue recorded during the work: https://github.com/CodexCoder21Organization/PlanRepository/blob/main/challenges/2026-07-29-1251-github-repository-search-skill-rejected-a-working.md

Next steps

1. Get an explicit decision on the intended acceptance load: three sequential rounds of six, or all 18 starvation scenarios at once. Do not edit the test until that is resolved.
2. If six-by-three is intended, decide explicitly whether changing the existing all-18 gate is authorized despite the no-weakening rule. Re-run both exact criteria before considering any result.
3. If all 18 simultaneous scenarios are intended, continue the diagnosis at the actual registration cancellation and synchronized relay-service boundary. Do not change timeouts, budgets, attempt caps, iteration counts, or the required outcome bars.
4. Review whether the three experimental commits should be retained. The latest contains a valid queued-cancellation bookkeeping correction, but none of the three has met acceptance.
5. Require the preferred-selection reproducer to produce zero wrong selections, the starvation reproducer to pass all 18 outcomes, the three named regression tests to pass, and the entire buildtest suite to be green.
6. Only after those gates pass, update the stale PR description with exact-head results. Do not merge.

Reusable knowledge

• A Future.cancel(true) issued before a submitted callable starts means the callable body and its finally never run. Any completion latch that relies only on that finally can remain permanently incomplete.
• A cached executor does not create useful parallelism around a synchronized registration method; it creates workers that spend their outer allowance waiting for the same monitor.
• Buildtest can execute separate stress files concurrently, so per-file concurrency can compound. Acceptance language and test harness structure must agree about the intended peak load.