Land the TinySite large-file fixes (TinySiteWui PR 7, FiledropEmbedded PR 22, FiledropApi PR 6), deploy them, and prove a 35 MB file serves whole
Remaining: re-review and land https://github.com/CodexCoder21Organization/TinySiteWui/pull/7 (head 1c8aefd: serve files in single-round-trip ranges so a >16 MiB file is no longer cut off at 16 MiB under HTTP 200), finish the review round on https://github.com/CodexCoder21Organization/FiledropEmbedded/pull/22 (head f747fd0: small-file download 7 -> 3 storage calls; needs the F1 replacement test + full suite), fold the doc fixes into https://github.com/CodexCoder21Organization/FiledropApi/pull/6 (head 4ebec2f: publishes the 524,286-byte one-round-trip limit), then publish FiledropApi 0.0.7 and filedrop-embedded (which also carries the merged-but-unpublished PR 18), bump FiledropServiceServer (branch download-range-uses-api-limit), redeploy filedrop-server and tinysite-wui, and verify a >16 MiB file uploads and serves byte-for-byte. Owner pre-approved merge+deploy after clean independent reviews. Nothing from this effort is deployed or published; all branches are pushed. kotlin.build (remote) checks wait ~2-2.5 h in a saturated buildtest queue. Also pending: owner approval of the Content Decryption capture (branch wip/content-decryption-zerotrillion, review copy https://tinysite.wasmserver.com/s/f185e67226/).
Claimed by fable-code-2026-10-17
Handoff document
Markdown
Land the TinySite large-file fixes, deploy them, and prove a 35 MB file serves whole
Written 2026-10-17 ~02:45 UTC. RE-VERIFY before acting. Every PR state, CI result, published version and deployed build below is a write-time snapshot. Re-check:
Published artifacts: curl -sI https://kotlin.directory/<group-path>/<artifact>/<v>/<artifact>-<v>.pom
Deployed builds: ssh -p 23 root@198.199.106.165 'ls -la /root/ContainerNursery/apps/tinysite-wui.jar /root/ContainerNursery-uploads/jars/ | grep -i filedrop', or the ContainerNursery CLI routes --json.
All delegated work was stopped at the owner's request; nothing is running.
Mission
The owner asked (2026-10-16): "investigate the tinysite issues, fix them, merge the changes, deploy, and upload the site." The original trigger was publishing a design capture of zerotrillion.com ("Content Decryption") to https://tinysite.wasmserver.com for review.
The owner pre-approved merging and deploying for this effort. Per their earlier authorization (memory tinysite_outage_fix_authorization_2026_10_08), merge each PR only after independent reviews are clean, and always git pull latest main before building a deploy.
Remaining:
Land the three open PRs: TinySiteWui 7, FiledropEmbedded 22, FiledropApi 6.
Publish FiledropEmbedded and FiledropApi.
Bump FiledropServiceServer and redeploy filedrop-server and tinysite-wui.
Verify that a file over 16 MiB (ideally the 35,125,250-byte one) uploads and serves byte-for-byte.
Ask the owner to approve the Content Decryption capture, then open the Good-UI-Designs PR.
What was found (the chain)
TinySite (tinysite-wui, repo TinySiteWui) stores each site as a "drop" in Filedrop (url://filedrop/, the filedrop-server built from FiledropServiceServer, which embeds FiledropEmbedded). Filedrop stores files in SimpleFileSystem vNext (url://simple-filesystem-vnext/). Every url:// hop goes through ContainerNursery on 198.199.106.165.
Three distinct problems were observed on 2026-10-16:
1. A large file was served truncated at exactly 16 MiB under HTTP 200
Observation: a site whose index.html is 35,125,250 bytes (site 4e7968caad, since expired or orphaned) returned exactly 16,777,216 bytes. The response carried the full Content-Length, then the connection closed early. A client reading to EOF sees "200 + 16 MiB". /index.html directly returned 503.
Mechanism (verified, reproduced): TinySite served files in 4 MiB downloadFileChunk calls (DOWNLOAD_RANGE_SIZE_BYTES). The FiledropApi contract permits 4 MiB, but FiledropServiceServer's sandboxed client (FiledropClientImpl) carries anything over MAX_RPC_READ_BYTES = 524,286 bytes as several serial round trips inside ONE call, and UrlResolver abandons any single call after 30 s. At the measured ~3 s per round trip, 8 round trips exceeded 30 s. The fifth 4 MiB range failed and the response stopped at 16 MiB.
Why one round trip is capped (verified in UrlProtocol):Libp2pHostFactory.kt:401-411 allows a 4 MiB per-connection / 8 MiB per-process response outbox and answers OUTBOX_FULL immediately (no waiting). So a 4 MiB range (5.59 M base64 characters) can never travel in one response. 524,286 is the largest multiple of 3 at or below 512 KiB (699,048 base64 characters), which leaves headroom for about 6 concurrent full reads per connection.
Reproducer: TinySiteWui tests/testLargeFileIsServedWholeWhenEachStorageCallIsSlow.kts on main fails with Expected <20971520>, actual <16777216> plus SJVM virtual method invocation timed out after 30s: ...FiledropClientImpl.downloadFileChunk, the exact production signature.
2. Committing a ~4 MB file exceeded the 30 s call limit
Three upload attempts each failed committing a different 4.1-4.6 MB image: HTTP 502 ... SJVM virtual method invocation timed out after 30s: ...commitFileUpload.
Mechanism: each commit made ~29 sequential storage calls, each costing several RPCs (~100 round trips). That came to ~13 s on a quiet host and >30 s at busy moments. File size was irrelevant: 2 KB to 500 KB files also hit it that day.
Ruled out: re-reading chunks for the SHA-256 (the trusted digest prefix is used), scanning all drops (upload ids carry the drop id), lock contention (0 BLOCKED threads).
Largely fixed already by a parallel session's https://github.com/CodexCoder21Organization/FiledropEmbedded/pull/18 (merged 2026-10-17 01:40 UTC). On current main a 3-chunk commit costs 25 storage calls (about 1.6 s at ~65 ms per call). This session's PR 23 would only have made it 23, so it was closed as superseded.
3. Every TinySite to Filedrop call cost ~3 s even for 100 bytes
Mechanism: each TinySite GET is one downloadFileChunk. On the old main that call read the drop's metadata.json 8 times plus the payload, and each read cost ~6 round trips: 48 isolated GETs, median 3.9 s, of which 3.6 s was 53-54 sequential storage calls at ~65 ms. Only 0.25 s was spent before filedrop's first storage call.
Ruled out: SJVM sandbox, relay routing and peer discovery.
PR 18 made the reads ranged (7 calls per download on current main). https://github.com/CodexCoder21Organization/FiledropEmbedded/pull/22 reduces that to 3 for manifests ≤ 64 KiB.
Also found (not TinySite code)
url://buildtest/ (the service behind the required kotlin.build (remote) check) had two phases. Recorded at https://github.com/CodexCoder21Organization/PlanRepository/blob/main/challenges/2026-10-17-0211-url-buildtest-stalled-2026-10-16-17-29-23-32z-on-phantom.md, with evidence on the host at /root/forensics/b1-buildtest-20261017/.
2026-10-16 17:29-23:32 UTC: stalled. Granted-but-dropletless runs blocked admission, while createDropletAsync/getDropletCreationStatus calls timed out after 30 s. A redeploy by another session cleared it.
Since then: not stuck but saturated at its 200-droplet limit (191 real droplets, ~40 completions/hour). PR checks wait ~2-2.5 h before admission. A restart is not recommended.
Raising the droplet limit costs money and is the owner's call.
The zerotrillion capture was 35 MB only because of how it was built. The photos were base64-embedded to make file:// work, and the site serves 1280-8192 px originals (22.7 MB). The capture now keeps 1000 px images as files (648 KB, whole capture 2.8 MB).
OPEN; bld-build SUCCESS; kotlin.build (remote) queued in buildtest
Serves each file in single-round-trip ranges (524,286 bytes). Round-1 adversarial review: no blockers. Round-1 test review's gaps M1-M6 were addressed at this head (30/30 local). The round-2 re-reviews were stopped mid-run and must be redone on this head.
OPEN; bld-build SUCCESS at fc678b4, checks re-running at f747fd0
Reads the whole manifest in one ranged read when it is ≤ 64 KiB: 3 calls per download instead of 7. Review at fc678b4: no correctness bug, but F1 (a test for a manifest growing between the pointer read and the whole read) and F2 (README/CHANGELOG stale) must be fixed. f747fd0 contains part of that round (the fallback continues from the replacement's pointer, plus docs). It has not had a full local suite run or re-review. Confirm F1's test exists and fails when the length guard at FiledropEmbedded.kt (~3168) is removed. Version should be 0.1.22.
Additive: publishes FiledropChunkLimits.MAX_DOWNLOAD_RANGE_BYTES = 524,286 (plus related constants) as API 0.0.7. Review: no blockers. Low-severity doc fixes L1-L5/N3 (name the real 4 MiB / 8 MiB outbox limit, concurrency headroom, legacy-allowance failure mode, durable migration plan) are on the WIP branch below, unverified. The constants are compile-time and get inlined into consumers, so fix the docs before publishing.
Test testE2eSjvmDownloadRangeAtApiMaximumIsOneRoundTrip.kts, fail-first form
At 4,194,304 it fails deterministically ("Expected <1>, actual <9>" round trips); at 524,286 it passes. Needs FiledropApi 0.0.7 published, then the client switched to the constant.
wip/tinysite-2026-10-16/: every lane brief, findings file and review report from this effort (t1-t4, b1, rev-*); wip/tinysite-outage-2026-10-08/: the earlier outage evidence
Reference
Deployed or published but not merged
Nothing from this effort is deployed or published.
Live at write time:
tinysite-wui.jar dated 2026-10-16 14:13 UTC, built from TinySiteWui main after PR 3. It does not contain PR 7.
filedrop-server filedrop-server-74bcdcdd-20261014T1319Z.jar, replaced in place 2026-10-16 09:19 UTC by another session. It predates PR 18 and PR 22.
simple-filesystem-vnext-a3501bb7-20261015T0532Z.jar, replaced in place 2026-10-16 20:48 UTC by another session.
Published: filedrop-api 0.0.6 is the latest (0.0.7 returns 404). filedrop-embedded 0.1.21 and 0.1.22 both return 404, so PR 18 is merged but not published.
Next steps
TinySiteWui PR 7: run fresh independent reviews (adversarial and test-comprehensiveness) on 1c8aefd. Previous reports: rev-t1-adv.md and rev-t1-tests.md in the PlanRepository folder above. Fix any findings, wait for kotlin.build (remote) (buildtest queue), merge.
FiledropEmbedded PR 22: finish the review round on f747fd0.
F1: add shorter / longer / equal-length replacement tests between the pointer read and the whole read, with exact read counts, and confirm they fail when the length guard is removed. A ready-made probe is in the PlanRepository folder report rev-t3c.md.
Confirm F2's README/CHANGELOG rewrite.
Set the version to 0.1.22, run the full local suite, get a re-review and green CI, merge.
FiledropApi PR 6: fold wip/t4-pr6-review-doc-fixes into the PR branch, build, re-review, green CI, merge, and publish 0.0.7. SHA-256-verify the published jar (memory: maven coordinate collisions).
Publish filedrop-embedded from main once PR 22 lands. This will include PR 18. Check which version is free first (0.1.21 is unpublished, but main's build.kts may already claim it). Byte-verify the published artifact.
FiledropServiceServer: open a PR from download-range-uses-api-limit. Switch FiledropClientImpl and its tests to FiledropChunkLimits (API 0.0.7), fold in the T1 concurrent test from wip/t4-fss-concurrent-range-test, and bump filedrop-embedded to the new version. Review, merge, build the fat jar from fresh main.
Deploy: redeploy filedrop-server (from the new FiledropServiceServer main) and tinysite-wui (from TinySiteWui main with PR 7). Use the container-nursery-deploy skill. Never (re)start long-lived services via HardwareControlFabric launch (memory never_launch_cn_via_hcf_launch_cgroup_512m).
Verify in production: upload a site with a file over 16 MiB through ~/.claude/skills/good-ui-designs/scripts/tinysite-deploy.sh and confirm it serves byte-for-byte (curl ... | cmp - file). Also measure a small-file GET and a commit against the earlier numbers (GET median 3.9 s; commit 13 s+).
Content Decryption:
Ask the owner whether https://tinysite.wasmserver.com/s/f185e67226/ (expires 2026-10-23) looks right. If it has expired, redeploy from the Good-UI-Designs branch above.
Pending owner choice: the hero is currently removed entirely. The owner once mentioned "replace the video with a black box/placeholder"; that was answered by explaining the hero was already removed, and it stays removed unless they say otherwise.
On approval, add the root README entry and open the PR (Good-UI-Designs has its own review flow; see the good-ui-designs skill).
Follow-ups worth separate handoffs (not required for this mission):
FiledropWui (Main.kt:45 / RawContentServlet.kt:182) and FiledropCli (Transfer.kt:23) still request 4 MiB ranges. Switch them to the API constant.
UrlResolver: one timed-out sandboxed call invalidates the shared connection for every caller. This was seen in buildtest's droplet client and in the 2026-10-08 TinySite outage.
BuildTestEmbedded: OUTPACED runs can keep their droplets ~18 min (teardown in cancelBuildRunAfterUploadFinalizationStopRequested is skipped if a later step throws), and outpace deadlines count queue wait.
SimpleFileSystem vNext: the read-session size is not taken from the pinned generation (F4 in rev-t3.md).
Reusable / operational knowledge
Host access: production is ssh -o BatchMode=yes -p 23 root@198.199.106.165 (read-only diagnostics). The ContainerNursery CLI is cs launch containernurserycli:container-nursery-cli:0.0.20 -r https://kotlin.directory -- --url https://api.nursery.wasmserver.com. A working cs is at ~/bin/cs; /usr/local/bin/coursier on the /code box is a wrong-architecture binary.
Headless Chromium on the /code box: the dependencies get wiped. Restore them from the Debian bookworm arm64 Packages.gz (see memory env_chromium_headless_ld_library_path) and install chromium-headless-shell via npx playwright-core install.
Git on the /code box: git identity and credentials may be unset. Run git config --global user.name codexcoder21; git config --global user.email codexcoder21@gmail.com; gh auth setup-git.
buildtest:kotlin.build (remote) for small PRs currently waits ~2-2.5 h behind agents' full-suite --remote runs. Run suites locally (scripts/test.bash --local) and don't add to the queue.
Overlap: a parallel session is also working on TinySite/Filedrop slowness (it authored PR 18). Check recent merges in FiledropEmbedded, FiledropServiceServer and TinySiteWui before starting, and rebase rather than duplicate.
Latest status report
18 reports
Runningfable-code-2026-10-1759325ee89 minutes ago
Status report: 2026-10-17 13:34 UTC
Original request: speed up TinySite page loads (with parallel prefetch), let TinySite take about 8 uploads at once, add the two management-page lists (unused files and recent 404s, with three-part timestamps), race GitHub-runner builds against the remote build service so slow remote builds cannot block merging, fold in the TinySite large-file effort (land its three pull requests, deploy them, prove a 35 MB file serves whole), and end by proving filedrop is working, since filedrop was touched throughout. Added 08:40: the owner delegated the five open decisions to me (constraint: never raise a container's keep-warm period beyond 5 minutes). Added 10:25: the owner reported https://tinysite.wasmserver.com/ showing an error. Added 13:09: the owner asked that merged changes be deployed as appropriate after each merge.
🟡 Status: RUNNING. Every remaining step is mine; no question is open.
Progress since the last report (13:14 UTC)
TinySite is deployed from main and the 35 MB proof is in. Build bbce49a (management lists, prefetch cache, large-file streaming) went live at 13:14 as a new jar (tinysite-wui-bbce49a-20261017T1314Z.jar; the previous jar is kept for rollback). Verified live: home page 8.3 s before, 1.95 s after, 1.17 s on the second visit; a recent site's asset 28.8 s cold then 0.26 s from cache; HEAD and a Range beyond 16 MiB correct; the management lists render; and the 35,125,250-byte file that was cut at 16 MiB yesterday now downloads whole, byte count equal to Content-Length (HTTP 200, 297 s through the uncached path because the file is above the cache's 32 MiB per-file limit and the old filedrop server answers each range's confirmation slowly). Two of the three 10-day-old sites still time out at storage (expected until the filedrop server redeploys); the third now loads.
One configuration gap found by the deploy, being fixed now: the new build's cache lives in a per-start temporary directory, so each 5-minute idle stop discards it and the first visitor after idle pays a cold cache on top of the cold chain (seen at 13:29: a restart and a 38 s 503, then 4.5 s and 0.9 s). A lane launched at 13:33 sets persistent host directories for the site cache and the usage-record state and raises the per-file cache limit to 64 MiB so the 35 MB file is cacheable, without touching keep-warm, then proves the cache survives a restart.
kompile-cli round 10 finished (https://github.com/CodexCoder21Organization/kompile-cli/pull/192 at b40845c): stop decisions and completion store raw failures without calling diagnostic getters, both reviewer reproducers 6/6, 60/60 stop tests, 327/327 full suite; round-11 review launched at 13:31, told to audit every remaining throwable read itself and to judge the new one-second optional-diagnostic rendering budget.
UrlProtocol coordinate bump enqueued (https://github.com/CodexCoder21Organization/UrlProtocol/pull/720, all checks green, queue position 1); publication follows its merge, then the storage-server pin bump.
Read-idle review is finding its own harness mistakes rather than product defects so far (a client-side close observation that did not join server cleanup; two test files whose function names no longer matched their filenames, which the runner silently skipped, now selected by file). Externalbrain round 2 is iterating on the clock-driven startup tests. Buildtest round 4's consumer suite is running under its cap (13:39). The filedrop pin bump's targeted tests all pass and it waits for the suite slot.
CLEAN; merges after a verified 8-file parallel publish
Delegated work at a glance
⏳ Running - GPT 6.1-sol high - 1 hour 28 minutes total time - under 1 minute since last update - Buildtest round 4: 59 focused scenarios green at 5b24edb; the consumer full gate is running (its main JVM accumulating CPU, so alive); hard cap 13:39, after which an unfinished run is reported as incomplete. Next expected checkpoint: suite result or cap exit, then candidate publication and pushes.
⏳ Running - GPT 6.1-sol high - 39 minutes total time - 2 minutes since last update - FiledropServiceServer pin bump to filedrop-embedded 0.1.27 with its two end-to-end proofs; all changed tests pass targeted checks; waiting for the machine-wide suite slot under its cap. Next expected checkpoint: suite counts or cap exit, PR opened.
⏳ Running - GPT 6.1-sol high - 17 minutes total time - under 1 minute since last update - Review of https://github.com/CodexCoder21Organization/UrlProtocol/pull/721: so far the remote-run analysis points at reviewer-harness issues (a close observation that did not join server cleanup; two test files whose selectors no longer matched and were silently skipped), now re-running by exact file selectors with a 73-entry manifest check. Next expected checkpoint: remote-failure explanation and verdict.
⏳ Running - GPT 6.1-sol high - 17 minutes total time - under 1 minute since last update - Externalbrain round 2 on https://github.com/CodexCoder21Organization/ExternalBrainWui/pull/58: moving the start deadline and attempt pacing onto the injected clock; a cleanup-failure-stops-retries test is currently red and being worked. Next expected checkpoint: the two deadline tests red-then-green in seconds, suite, CI.
⏳ Running - GPT 6.1-sol high - 3 minutes total time - under 1 minute since last update - Round-11 review of https://github.com/CodexCoder21Organization/kompile-cli/pull/192 at b40845c: its own audit of every throwable read on the decision path and a judgement of the new one-second diagnostic rendering budget. Next expected checkpoint: the verdict.
⏳ Running - GPT 6.1-sol high - 1 minute total time - under 1 minute since last update - TinySite route configuration: persistent cache and state directories, 64 MiB per-file cache limit, restart, prove the cache survives a restart and the 35 MB file serves from cache the second time; revert on failure; keep-warm untouched. Next expected checkpoint: env applied, restart verified.
⚪ Not running (finished/dead) - GPT 6.1-sol high - 13 minutes total time - finished 13:26 - Deployed TinySite bbce49a to production under a new jar name and verified it (timings, HEAD and Range, management lists, the 35,125,250-byte file whole; old-site timeouts recorded as expected). Needed CLI 0.0.22 for a route-less upload. Nothing further is expected from it.
⚪ Not running (finished/dead) - GPT 6.1-sol high - 1 hour 10 minutes total time - finished 13:15 - kompile-cli round 10 at b40845c (raw failures stored without diagnostic getters; 327/327). Round-11 review launched. Nothing further is expected from it.
How the fixes work
TinySite management lists, prefetch cache and large-file streaming (merged, deployed 13:14): every request updates an in-memory record written off the request path with per-entry generations; a bounded on-disk cache is filled in parallel by owned storage calls that stop interrupts and drains, one version per answer; files are served in 524,286-byte ranges from the published API constant, and the uncached path confirms size and upload time after every range.
Filedrop old-drop read, manifest read and group commit (merged, published, server pin bump in progress): a serving read returns the drop's original complete metadata in two storage calls regardless of file count; one ranged read of the whole manifest; uploads touching the same bookkeeping document are batched so one leader does one read and one write per batch with no lock held during I/O.
Filedrop API constants (merged, published) and the server-side fix (merged): the download range and legacy limits are compile-time constants; the served client validates the caller's whole range before splitting and treats a padded part as terminal.
Storage library (merged, published): the manager's close interrupts and joins its trash-reclaim workers before releasing the root and refuses to join from inside a callback that holds a manager lock.
Connection library (merged, coordinate bump in the queue) and its read-idle follow-up (draft, in review): a completed answer that does not fit the response queue waits instead of being dropped; each paused answer has one owner-tracked deadline retired exactly once; separately, pending handlers count as activity so the idle check cannot close a stream under them.
kompile-cli (round 11 review): the race's remote run is stopped on wait expiry or exit with a one-time fallback; every exit passes through one completion boundary that cannot itself fail; the decision path stores raw failures and never calls a diagnostic getter.
Buildtest CPU (round 4): journal compaction does per-row bounded work and streams its staging delta; the startup row cache is bounded by the decoded footprint it retains.
Handoff service (deployed): report bodies are archived out of the live state file so the heap no longer grows per report.
ExternalBrainWui startup (round 2): the HTTP server binds before any dependency is contacted; dependencies open lazily with at most three bounded attempts paced by the injected clock; each route is gated only on the dependency it uses.
Blockers
🟡 None; every item has a lane running or a brief ready for the next slot.
Landing parallelization sweep: the TinySite deploy ran as soon as authorization arrived and its configuration follow-up started within ten minutes of the finding; the kompile-cli review started the moment round 10 pushed; the coordinate bump was enqueued at the first green check. The one shared gate remains the local full-suite slot, held by the buildtest consumer gate until 13:39.
Plan changes: a TinySite route-configuration step (persistent cache and state, 64 MiB cache file limit) joins the deploy track; the filedrop and storage redeploys follow their pin bumps as planned.
Next steps: finish the TinySite cache-persistence change, merge and publish the UrlProtocol bump, land the filedrop pin bump and redeploy filedrop, bump and redeploy the storage server, merge the kompile-cli, externalbrain, read-idle and buildtest PRs as their rounds come back clean and deploy what applies, then prove an 8-file parallel publish, old and new sites loading cold, faster page loads and a working filedrop.
Handoff
url://handoff/handoffs/hf-2026-10-17-land-the-tinysite-speed-and-parallel-upload-fixes-finish-the-ci-capacity-fixes-and-redeploy-tinysite-filedrop-and-storage, viewable at https://www.handoff.wasmserver.com/handoffs/hf-2026-10-17-land-the-tinysite-speed-and-parallel-upload-fixes-finish-the-ci-capacity-fixes-and-redeploy-tinysite-filedrop-and-storage; this report also goes to the folded-in large-file handoff, whose deploy and 35 MB proof are now done (its remaining item is the filedrop server redeploy). Lane artifacts: https://github.com/CodexCoder21Organization/PlanRepository/tree/wip/tinysite-ci-handoff-artifacts-2026-10-17.
Top lessons
Verify a deploy against the first visit after idle, not only against a warm process. The TinySite deploy passed every check while warm, and three minutes of idleness later the first visitor got a 38-second failure and a cold cache, because the cache lived in a per-start temp directory nobody had configured. A deploy's verification must include stop, restart and first request, and every durable artifact the application keeps (caches, state) must be given a persistent path on the route.
Deploy per service as its merges land, with live verification, instead of batching every deploy to the end. Five TinySite PRs had merged over seven hours while production kept serving the defective build. Treat "merged" as the trigger for "deploy and verify" whenever the service's dependencies are published, keep the previous artifact for rollback, and record what is live versus what is on main.
A test that waits on a real production deadline is calibrated to the host even when no number in it was tuned. Two startup scenarios pass locally and fail on the shared build service because they let the resolver's real 30-second deadline expire up to three times. Drive every deadline a test depends on through the injected clock so the scenario proves the ordering in seconds anywhere.
Earlier reports
Runningfable-code-2026-10-1759325ee828 minutes ago
Runningfable-code-2026-10-1759325ee850 minutes ago