jeroen/cartopolis

Watch

Fork 0

main is red on `6b4dd54f` #298

New issue

Closed

opened 2026-09-10 14:33:54 +00:00 by viberfox-agent · 5 comments

viberfox-agent commented

2026-09-10 14:33:54 +00:00

Collaborator

Problem

main is red at 6b4dd54f because the Headless flicker smoke (street) step in the test cartopolis job runs out of wall-clock time. Every unit suite passes; nothing fails an --expect.

The step is .forgejo/workflows/ci.yml:472-489, with timeout-minutes: 15 at .forgejo/workflows/ci.yml:474. --flicker captures the viewpoint twice, ~5 cm apart. In the failing runs the first capture's PNG lands at ~10½ minutes and the second never finishes; the runner kills the step at 900 s and logs ⚙️ [runner]: context deadline exceeded.

The job-log ids returned by /actions/runs/{n}/jobs do not match the logs served by /actions/jobs/{id}/logs — the log for job 1331 is b5a9c9ad, not 6b4dd54f. The correct log for 6b4dd54f is job 1352; verify by grepping the log's fetch … +<sha>:refs/remotes/origin/main line before trusting it.

This is not a flake. Measured from each log — step start (Running \target/debug/cartopolis --shot /tmp/flicker.png …`) to either flicker pair measured or the runner kill, at the identical pinned viewpoint (53.2194,6.5665,100`, noon, clear, dry, 640×360):

commit	step wall	to 1st PNG	`settled_in` (shot 1)	`frame_ms`	`fetch_mb`	verdict
`6473ddb1`	680 s	411 s	45.9 s	2069	80.15	pass
`856f666b`	654 s	316 s	29.5 s	2084	79.91	pass
`ae198d53`	612 s	304 s	29.9 s	2428	79.30	pass
`b0e2a24e`	854 s	509 s	45.8 s	2798	80.17	pass
`cd5d1b84`	733 s	354 s	29.4 s	2810	86.27	pass
`dcfa1426`	733 s	362 s	29.5 s	2852	88.20	pass (job red on `cargo fmt`)
`b5a9c9ad`	879 s	638 s	46.3 s	2837	141.07	killed
`5d2e20b1`	899 s	613 s	46.0 s	3031	138.52	killed
`6b4dd54f`	884 s	628 s	46.5 s	3181	141.17	killed

Two things happened, and neither alone is the whole story:

The scene started fetching ~60 % more bytes. fetch_mb goes 79–88 → 138–141 with no overlap, across three consecutive runs of the same pinned viewpoint. The commit at that boundary is 13777216 perf(map): bound, order and share the per-cell streaming path (dcfa1426 → [1377721] → b5a9c9ad; b5a9c9ad itself is a whitespace-only style(sun) change). The same boundary shows fetch_errors 3 → 13 and worker_split's lod22 busy time 9.1 s → 17.9 s.
The frame got ~12 % slower across 5d2e20b1 and 6b4dd54f: grass_patches 145 → 209, grass_slots 1,511,680 → 2,403,904, draws 1275 → 1302, frame_ms 2837 → 3181.

And the budget never had margin. The worst green run used 854 s of 900 — 5 % headroom. Fixing (1) alone puts the gate back to roughly where it was, i.e. one heavy commit from red again.

Why the capture can overrun a wall-clock timeout at all: the harness's --wait 120 and --settle 2 are counted on the virtual clock (shot_harness.rs:2514 and shot_harness.rs:2630 both accumulate time.delta_secs(); the settle test is shot_harness.rs:2635), which Bevy clamps at max_delta = 0.25 s. At 3.18 s/frame that is ~12.7× wall, so --wait 120 permits ~25 minutes per capture and --flicker doubles it. QUIESCE_MAX_S (shot_harness.rs:138, compared at shot_harness.rs:2683) is measured on the same virtual clock. Only the frame-time readouts use Time<Real> (shot_harness.rs:2522). There is no wall-clock ceiling anywhere in the harness, and adding one is out of scope — docs/notes/headless-shots-software-renderer.md:142 already documents this and records that switching to real time was considered and rejected as "a deliberate trade rather than an oversight", because it would make every CI capture less complete for the same flag values.

Leading hypothesis for (1), not established. 1377721 added a promotion sweep to lod22: cells in the outermost ring are built without door panels and rebuilt when they come closer (lod22.rs:635-664), with the built detail recorded at dispatch (lod22.rs:697-698) and the boundary at lod22.rs:105-112. docs/notes/streaming-order-and-residency.md:76-80 claims a promotion needs the camera to cross a whole cell boundary. A --shot camera is static after placement, so a static capture should see zero promotions — yet lod22's worker time doubled and the byte count rose by ~53 MB at that commit, which is about what re-fetching a 5×5 ring of 3DBAG cells costs. radius_bias=0 in every dump, so load_control (load_control.rs:152-160) is not moving the ring. Other candidates in the same commit: systems::cell_bundle's "one 404 per covered cell until it latches off", and the global platform::fetch_gate cap (fetch_gate.rs:79-87). Confirm before fixing — the implementer should not take this paragraph as the diagnosis.

Approach

Two parts. Part 1 is the cause; part 2 is why the gate stayed one commit away from red for a month.

1 — crates/cartopolis streaming path. Find what 13777216 made fetch ~53 MB more at a static viewpoint and remove it. Start by reproducing the flicker capture at 6b4dd54f and again with the promotion sweep short-circuited (make door_detail in lod22.rs:110-112 return Near unconditionally) and diffing fetch_mb / worker_split from --dump-state. If that accounts for the bytes, the fix belongs in lod22.rs's promotion filter (lod22.rs:635-644) — a cell must not be promotable against the same ring_distance it was dispatched under. If it does not, work through systems/map/cell_bundle.rs and platform/fetch_gate.rs next. Whatever is found, correct docs/notes/streaming-order-and-residency.md:76-80, whose claim the CI evidence contradicts.

2 — .forgejo/workflows/ci.yml. Re-size the flicker step's budget from the post-fix measured worst case rather than leaving it at a number that was already only 5 % clear. Do the same review for the two sibling steps that carry the same 15 minutes (ci.yml:436-438, ci.yml:510-512) — neither is failing, but neither number was derived either. Record the measurement and the headroom in docs/notes/headless-shots-software-renderer.md, which already owns this renderer's timing facts.

Also in ci.yml: on a timeout-minutes kill the step's || { … cat /tmp/flicker.json … } block (ci.yml:483-488) never runs, so a red run hands back no metrics at all — which is most of why this ticket cost a log-archaeology session. Put the run under a shell timeout slightly under the step budget so the dump is printed on the slow path too.

Acceptance criteria

The mechanism behind fetch_mb 88 → 141 at the flicker viewpoint is identified and named in the commit body, with the before/after --dump-state numbers that show it.
With the fix applied, a local flicker capture at 6b4dd54f's viewpoint reports fetch_mb back in the 79–88 range (± the genuine content added by 5d2e20b1 and 6b4dd54f, stated explicitly if it is not).
docs/notes/streaming-order-and-residency.md:76-80 either states a property that now holds, or says plainly what it got wrong and when.
The flicker step's timeout-minutes is set from a measured worst case with the headroom stated in a comment, not left at an unexamined 15.
A timeout-killed flicker step prints /tmp/flicker.json (or says the run died before capturing) instead of ending on a bare context deadline exceeded.
cargo test -p cartopolis and cargo fmt -p cartopolis -p cartopolis_geo -p cartopolis_core -p cartopolis_simulator -p cartopolis_android --check pass.
The test cartopolis job is green on main, with the flicker step reaching flicker pair measured and flicker_px <= 1500.

Verification

cargo test -p cartopolis
cargo fmt -p cartopolis -p cartopolis_geo -p cartopolis_core -p cartopolis_simulator -p cartopolis_android --check

# The failing capture, exactly as CI runs it. Time it.
CARTO_TILE_URL=https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y} \
  cargo run --locked -p cartopolis -- \
    --shot /tmp/flicker.png --dump-state /tmp/flicker.json \
    --flicker --time 12 --fog 0 --clouds 0 --rain 0 \
    --at 53.2194,6.5665,100 --look=-60,0 \
    --size 640x360 --settle 2 --wait 120 --hide-ui \
    --expect 'settled==true' --expect 'flicker_px<=1500'

The numbers to read out of /tmp/flicker.json and the shot state log line: fetch_mb, fetch_count, fetch_errors, worker_split (the lod22: and surfaces: fields), settled_in, frame_ms, and the wall time from the first camera placed line to flicker pair measured.

To fetch a CI log for comparison, probe /repos/$FORGEJO_REPO/actions/jobs/<id>/logs and confirm the SHA in the log's fetch line — the ids from /actions/runs/{n}/jobs are wrong. Known-good ids: 1352 = 6b4dd54f (red), 1319 = cd5d1b84 (last green flicker run), 1324 = dcfa1426 (last green flicker step).

Cost and environment. This container does render — lavapipe is present at /usr/share/vulkan/icd.d/lvp_icd.json, contradicting the "cannot render" line in the refinement brief and the stale claim in the global instructions. But one flicker capture is ~11–15 minutes on top of a debug build of cartopolis, the box is shared with nominatim/overpass/other agents, and renders share the box — concurrent captures make the timings meaningless. Budget for it and run one at a time. Colour, exposure and lighting are not evidence here; geometry, byte counts and timings are.

The only thing that cannot be checked locally is the final criterion: main going green needs a real CI run after the merge.

Out of scope

Making --wait / --settle count real seconds. Already considered and rejected — docs/notes/headless-shots-software-renderer.md:142.
Reverting 13777216. It fixes real handset problems (the 991 MB → 371 MB residency work); the ask is to find and remove the specific regression, not to undo the commit.
The grass_slots and draws growth from 5d2e20b1 and 6b4dd54f. That is ~12 % of frame time and is content the map is meant to have; it is context for the budget, not a defect to fix here.
The wasm & android targets job, which is red only because it needs: test.
The globe-tile 404s at z3 in the orbit smoke (tiles.cartopolis.org/tiles/osm/3/*/7). Present in green runs too; not this failure.

Open questions

None blocking.

Branch: fix/298-flicker-smoke-overruns-budget

Original request

The last commit on main that CI ran for is 6b4dd54f, and it did not pass:

test cartopolis — failure

Nothing can be deployed while this stands — tools/deploy-main gates on it — so this
comes before anything on the frontier.

Read the failing job's log, reproduce it locally, and fix the cause. If the failure is
the runner rather than the code (a flake, a cache miss, a missing tool), say so on this
ticket and close it rather than changing code to suit it.

_{Filed by the autopilot.}

_{🤖 Refined by the viberfox issue agent. Reply with @agent refine and what is wrong to have this rewritten.}

## Problem `main` is red at `6b4dd54f` because the **`Headless flicker smoke (street)`** step in the `test cartopolis` job runs out of wall-clock time. Every unit suite passes; nothing fails an `--expect`. The step is `.forgejo/workflows/ci.yml:472-489`, with `timeout-minutes: 15` at `.forgejo/workflows/ci.yml:474`. `--flicker` captures the viewpoint twice, ~5 cm apart. In the failing runs the **first** capture's PNG lands at ~10½ minutes and the second never finishes; the runner kills the step at 900 s and logs `⚙️ [runner]: context deadline exceeded`. The job-log ids returned by `/actions/runs/{n}/jobs` do not match the logs served by `/actions/jobs/{id}/logs` — the log for job `1331` is `b5a9c9ad`, not `6b4dd54f`. The correct log for `6b4dd54f` is job **1352**; verify by grepping the log's `fetch … +<sha>:refs/remotes/origin/main` line before trusting it. **This is not a flake.** Measured from each log — step start (`Running \`target/debug/cartopolis --shot /tmp/flicker.png …\``) to either `flicker pair measured` or the runner kill, at the identical pinned viewpoint (`53.2194,6.5665,100`, noon, clear, dry, 640×360): | commit | step wall | to 1st PNG | `settled_in` (shot 1) | `frame_ms` | `fetch_mb` | verdict | |---|---|---|---|---|---|---| | `6473ddb1` | 680 s | 411 s | 45.9 s | 2069 | 80.15 | pass | | `856f666b` | 654 s | 316 s | 29.5 s | 2084 | 79.91 | pass | | `ae198d53` | 612 s | 304 s | 29.9 s | 2428 | 79.30 | pass | | `b0e2a24e` | 854 s | 509 s | 45.8 s | 2798 | 80.17 | pass | | `cd5d1b84` | 733 s | 354 s | 29.4 s | 2810 | 86.27 | pass | | `dcfa1426` | 733 s | 362 s | 29.5 s | 2852 | 88.20 | pass (job red on `cargo fmt`) | | `b5a9c9ad` | **879 s** | 638 s | 46.3 s | 2837 | **141.07** | **killed** | | `5d2e20b1` | **899 s** | 613 s | 46.0 s | 3031 | **138.52** | **killed** | | `6b4dd54f` | **884 s** | 628 s | 46.5 s | 3181 | **141.17** | **killed** | Two things happened, and neither alone is the whole story: 1. **The scene started fetching ~60 % more bytes.** `fetch_mb` goes 79–88 → 138–141 with no overlap, across three consecutive runs of the same pinned viewpoint. The commit at that boundary is `13777216 perf(map): bound, order and share the per-cell streaming path` (`dcfa1426` → [`1377721`] → `b5a9c9ad`; `b5a9c9ad` itself is a whitespace-only `style(sun)` change). The same boundary shows `fetch_errors` 3 → 13 and `worker_split`'s `lod22` busy time 9.1 s → 17.9 s. 2. **The frame got ~12 % slower** across `5d2e20b1` and `6b4dd54f`: `grass_patches` 145 → 209, `grass_slots` 1,511,680 → 2,403,904, `draws` 1275 → 1302, `frame_ms` 2837 → 3181. **And the budget never had margin.** The worst green run used 854 s of 900 — 5 % headroom. Fixing (1) alone puts the gate back to roughly where it was, i.e. one heavy commit from red again. Why the capture can overrun a wall-clock timeout at all: the harness's `--wait 120` and `--settle 2` are counted on the **virtual** clock (`shot_harness.rs:2514` and `shot_harness.rs:2630` both accumulate `time.delta_secs()`; the settle test is `shot_harness.rs:2635`), which Bevy clamps at `max_delta` = 0.25 s. At 3.18 s/frame that is ~12.7× wall, so `--wait 120` permits ~25 minutes *per capture* and `--flicker` doubles it. `QUIESCE_MAX_S` (`shot_harness.rs:138`, compared at `shot_harness.rs:2683`) is measured on the same virtual clock. Only the frame-time readouts use `Time<Real>` (`shot_harness.rs:2522`). **There is no wall-clock ceiling anywhere in the harness, and adding one is out of scope** — `docs/notes/headless-shots-software-renderer.md:142` already documents this and records that switching to real time was considered and rejected as "a deliberate trade rather than an oversight", because it would make every CI capture less complete for the same flag values. **Leading hypothesis for (1), not established.** `1377721` added a promotion sweep to `lod22`: cells in the outermost ring are built without door panels and rebuilt when they come closer (`lod22.rs:635-664`), with the built detail recorded at dispatch (`lod22.rs:697-698`) and the boundary at `lod22.rs:105-112`. `docs/notes/streaming-order-and-residency.md:76-80` claims a promotion needs the camera to cross a whole cell boundary. A `--shot` camera is static after placement, so a static capture should see zero promotions — yet lod22's worker time doubled and the byte count rose by ~53 MB at that commit, which is about what re-fetching a 5×5 ring of 3DBAG cells costs. `radius_bias=0` in every dump, so `load_control` (`load_control.rs:152-160`) is not moving the ring. Other candidates in the same commit: `systems::cell_bundle`'s "one 404 per covered cell until it latches off", and the global `platform::fetch_gate` cap (`fetch_gate.rs:79-87`). **Confirm before fixing** — the implementer should not take this paragraph as the diagnosis. ## Approach Two parts. Part 1 is the cause; part 2 is why the gate stayed one commit away from red for a month. **1 — `crates/cartopolis` streaming path.** Find what `13777216` made fetch ~53 MB more at a static viewpoint and remove it. Start by reproducing the flicker capture at `6b4dd54f` and again with the promotion sweep short-circuited (make `door_detail` in `lod22.rs:110-112` return `Near` unconditionally) and diffing `fetch_mb` / `worker_split` from `--dump-state`. If that accounts for the bytes, the fix belongs in `lod22.rs`'s promotion filter (`lod22.rs:635-644`) — a cell must not be promotable against the same `ring_distance` it was dispatched under. If it does not, work through `systems/map/cell_bundle.rs` and `platform/fetch_gate.rs` next. Whatever is found, correct `docs/notes/streaming-order-and-residency.md:76-80`, whose claim the CI evidence contradicts. **2 — `.forgejo/workflows/ci.yml`.** Re-size the flicker step's budget from the post-fix measured worst case rather than leaving it at a number that was already only 5 % clear. Do the same review for the two sibling steps that carry the same 15 minutes (`ci.yml:436-438`, `ci.yml:510-512`) — neither is failing, but neither number was derived either. Record the measurement and the headroom in `docs/notes/headless-shots-software-renderer.md`, which already owns this renderer's timing facts. Also in `ci.yml`: on a `timeout-minutes` kill the step's `|| { … cat /tmp/flicker.json … }` block (`ci.yml:483-488`) never runs, so a red run hands back no metrics at all — which is most of why this ticket cost a log-archaeology session. Put the run under a shell `timeout` slightly under the step budget so the dump is printed on the slow path too. ## Acceptance criteria - [ ] The mechanism behind `fetch_mb` 88 → 141 at the flicker viewpoint is identified and named in the commit body, with the before/after `--dump-state` numbers that show it. - [ ] With the fix applied, a local flicker capture at `6b4dd54f`'s viewpoint reports `fetch_mb` back in the 79–88 range (± the genuine content added by `5d2e20b1` and `6b4dd54f`, stated explicitly if it is not). - [ ] `docs/notes/streaming-order-and-residency.md:76-80` either states a property that now holds, or says plainly what it got wrong and when. - [ ] The flicker step's `timeout-minutes` is set from a measured worst case with the headroom stated in a comment, not left at an unexamined 15. - [ ] A `timeout`-killed flicker step prints `/tmp/flicker.json` (or says the run died before capturing) instead of ending on a bare `context deadline exceeded`. - [ ] `cargo test -p cartopolis` and `cargo fmt -p cartopolis -p cartopolis_geo -p cartopolis_core -p cartopolis_simulator -p cartopolis_android --check` pass. - [ ] The `test cartopolis` job is green on `main`, with the flicker step reaching `flicker pair measured` and `flicker_px <= 1500`. ## Verification ```bash cargo test -p cartopolis cargo fmt -p cartopolis -p cartopolis_geo -p cartopolis_core -p cartopolis_simulator -p cartopolis_android --check # The failing capture, exactly as CI runs it. Time it. CARTO_TILE_URL=https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y} \ cargo run --locked -p cartopolis -- \ --shot /tmp/flicker.png --dump-state /tmp/flicker.json \ --flicker --time 12 --fog 0 --clouds 0 --rain 0 \ --at 53.2194,6.5665,100 --look=-60,0 \ --size 640x360 --settle 2 --wait 120 --hide-ui \ --expect 'settled==true' --expect 'flicker_px<=1500' ``` The numbers to read out of `/tmp/flicker.json` and the `shot state` log line: `fetch_mb`, `fetch_count`, `fetch_errors`, `worker_split` (the `lod22:` and `surfaces:` fields), `settled_in`, `frame_ms`, and the wall time from the first `camera placed` line to `flicker pair measured`. To fetch a CI log for comparison, probe `/repos/$FORGEJO_REPO/actions/jobs/<id>/logs` and confirm the SHA in the log's fetch line — the ids from `/actions/runs/{n}/jobs` are wrong. Known-good ids: `1352` = `6b4dd54f` (red), `1319` = `cd5d1b84` (last green flicker run), `1324` = `dcfa1426` (last green flicker step). **Cost and environment.** This container does render — lavapipe is present at `/usr/share/vulkan/icd.d/lvp_icd.json`, contradicting the "cannot render" line in the refinement brief and the stale claim in the global instructions. But one flicker capture is ~11–15 minutes on top of a debug build of `cartopolis`, the box is shared with nominatim/overpass/other agents, and `renders share the box` — concurrent captures make the timings meaningless. Budget for it and run one at a time. Colour, exposure and lighting are not evidence here; geometry, byte counts and timings are. The only thing that cannot be checked locally is the final criterion: `main` going green needs a real CI run after the merge. ## Out of scope - Making `--wait` / `--settle` count real seconds. Already considered and rejected — `docs/notes/headless-shots-software-renderer.md:142`. - Reverting `13777216`. It fixes real handset problems (the 991 MB → 371 MB residency work); the ask is to find and remove the specific regression, not to undo the commit. - The `grass_slots` and `draws` growth from `5d2e20b1` and `6b4dd54f`. That is ~12 % of frame time and is content the map is meant to have; it is context for the budget, not a defect to fix here. - The `wasm & android targets` job, which is red only because it `needs: test`. - The globe-tile `404`s at z3 in the orbit smoke (`tiles.cartopolis.org/tiles/osm/3/*/7`). Present in green runs too; not this failure. ## Open questions None blocking. --- Branch: `fix/298-flicker-smoke-overruns-budget` <details><summary>Original request</summary> The last commit on `main` that CI ran for is `6b4dd54f`, and it did not pass: - `test cartopolis` — failure Nothing can be deployed while this stands — `tools/deploy-main` gates on it — so this comes before anything on the frontier. Read the failing job's log, reproduce it locally, and fix the cause. If the failure is the runner rather than the code (a flake, a cache miss, a missing tool), say so on this ticket and close it rather than changing code to suit it. Filed by the autopilot.  </details> 🤖 Refined by the viberfox issue agent. Reply with **@agent refine** and what is wrong to have this rewritten.

viberfox-agent added the

labels

2026-09-10 14:33:54 +00:00

viberfox-agent added this to the Viberfox project

2026-09-10 14:34:06 +00:00

viberfox-agent commented

2026-09-10 14:34:08 +00:00

Author

Collaborator

🤖 Refining this before anything gets built — reading the code, no branch, no commits. If it turns out I'd have to guess at the requirements I'll stop and ask instead.

viberfox-agent added

agent:refined

and removed

agent:refining

labels

2026-09-10 14:42:11 +00:00

viberfox-agent commented

2026-09-10 14:42:11 +00:00

Author

Collaborator

🤖 Refined. The description above is now the spec; I'll pick it up for implementation on the next poll.

If the direction is wrong, say so now — @agent refine with a correction rewrites it, and agent:skip stops me.

_{🤖 viberfox issue agent on the VPS — 56 turns · $5.74 · session 2a2c30bc-0a11-4fb0-94ec-c2911e444dd6. Reply with @agent to continue this session.}

🤖 **Refined.** The description above is now the spec; I'll pick it up for implementation on the next poll. If the direction is wrong, say so now — **@agent refine** with a correction rewrites it, and `agent:skip` stops me. --- 🤖 viberfox issue agent on the VPS — 56 turns · $5.74 · session `2a2c30bc-0a11-4fb0-94ec-c2911e444dd6`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:running

and removed

agent:refined

labels

2026-09-10 14:42:38 +00:00

viberfox-agent commented

2026-09-10 14:42:40 +00:00

Author

Collaborator

🤖 Picked this up — working on branch fix/298-flicker-smoke-overruns-budget in a fresh worktree on the VPS. I'll report back here when I'm done.

_{Label an issue agent:skip to keep me off it, or driven to keep it in a session you are driving.}

🤖 Picked this up — working on branch `fix/298-flicker-smoke-overruns-budget` in a fresh worktree on the VPS. I'll report back here when I'm done. Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.

viberfox-agent commented

2026-09-10 15:27:41 +00:00

Author

Collaborator

The session was killed after hitting the 45 minute limit.

No commits were made.

_{🤖 viberfox issue agent on the VPS — . Reply with @agent to continue this session.}

The session was killed after hitting the 45 minute limit. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — . Reply with **@agent** to continue this session.

viberfox-agent added

agent:failed

and removed

agent:running

labels

2026-09-10 15:27:41 +00:00

viberfox-agent referenced this issue

2026-09-11 00:39:53 +00:00

alreadyFiled only ever sees 50 issues, so every autopilot dedupe key silently expires — #206 was QA'd twice #281

jeroen commented

2026-09-26 23:57:42 +00:00

Owner

No longer reproduces: on current main e3ea1346, cargo test --locked --workspace --exclude cartopolis_android exits 0 and cargo fmt --check over the five owned crates exits 0 (nightly run, 2026-09-26 23:5x UTC, slot vps-1). Closing.

No longer reproduces: on current main `e3ea1346`, `cargo test --locked --workspace --exclude cartopolis_android` exits 0 and `cargo fmt --check` over the five owned crates exits 0 (nightly run, 2026-09-26 23:5x UTC, slot vps-1). Closing.

jeroen closed this issue

2026-09-26 23:57:42 +00:00