jeroen/cartopolis

Watch

Fork 0

main is red on `5d2e20b1` #297

New issue

Closed

opened 2026-09-10 12:43:41 +00:00 by viberfox-agent · 5 comments

viberfox-agent commented

2026-09-10 12:43:41 +00:00

Collaborator

Problem

main is red on 5d2e20b1, but no test failed. Every suite in the test cartopolis job passed — 912 in cartopolis, 251 in cartopolis_geo, 108 in cartopolis_simulator, plus the rest — and cargo fmt --check passed too. The job died because the Headless flicker smoke (street) step hit its wall-clock ceiling (.forgejo/workflows/ci.yml:472-487, timeout-minutes: 15). The runner logged context deadline exceeded and killed the process; because the step was killed rather than exited, the step's own || { cat /tmp/flicker.json } diagnostic never ran, so the job handed back no metrics at all.

The failing job's log is job id 1350 (GET $FORGEJO_API/repos/$FORGEJO_REPO/actions/jobs/1350/logs). Note the run-id trap: actions/runs/723/jobs resolves 723 as a run id, not the run number shown in the UI, and returns a different day's job.

What the smoke actually did

	last green render `dcfa1426`, job 1324, 09-09 18:43	first red `b5a9c9ad`, job 1331, 09-09 21:21	this ticket `5d2e20b1`, job 1350, 09-10 11:34
shot 1 placed → settled	5 m 53 s	10 m 29 s	10 m 04 s
whole step	12 m 12 s (passed, `flicker_px=505`)	timed out	timed out
`fetch_count` / `fetch_mb`	332 / 88.2 MB	365 / 141.1 MB	356 / 138.5 MB
`fetch_ttfb_ms` (cumulative)	36,196	74,135	73,219
`fetch_errors`	3	13	13
`worker_split` lod22 / surfaces	25 / 17	50 / 26	50 / 26
`draws` / `frame_ms`	1275 / 2852	1275 / 2837	1302 / 3031
`grass_slots`	1,511,680	1,511,680	2,403,904
`radius_bias`	–	0	0

Two independent readings, one conclusion:

The drawn frame barely moved. draws 1275 → 1302 and frame_ms 2837 → 3031 across the whole window. The grass work of 4e77f8e/04b9844 (slots 1.51 M → 2.40 M) costs about 7 % of a frame and is not what broke this.
The time to stream the street scene doubled, with no camera or viewpoint change, at one commit.

The bisect

git log --name-only dcfa142..b5a9c9a gives exactly one commit that touches the client: 1377721 perf(map): bound, order and share the per-cell streaming path (27 files, +1947/−237). The other two commits in the window are tools/autopilot.ts (b488d29, 99e942d), which cannot change a frame, and b5a9c9a itself, which rewraps one expression in crates/cartopolis/src/utils/sun.rs.

1377721 did not touch the settle test — its shot_harness.rs diff only adds the fetch_outstanding and radius_bias readouts. So the harness is measuring the client honestly; the client got slower.

Two things inside that commit are candidates, and they are separable:

The global fetch cap. platform::fetch_gate::capacity() is io_threads × 4 floored at 16 (crates/cartopolis/src/platform/fetch_gate.rs:116-120, CAPACITY_PER_IO_THREAD at :87, FALLBACK_CAPACITY at :82). The CI container reports map streaming initialized io=4 cpu=7 in both the green and red runs, so capacity there is 16 — against the "~55 simultaneous jobs" the commit body says existed before. On a link whose cumulative TTFB for one street scene is 36 s, cutting concurrency by ~3.5× lands directly on wall clock. This part is deliberate and exists to protect a handset's 4-thread IO pool.
More work, not just slower work. fetch_mb 88 → 141 (+60 %), lod22 worker jobs 25 → 50, surfaces 17 → 26. A concurrency cap changes when bytes arrive, never how many. Something in the commit widened what the street viewpoint streams. It is not load_control tightening or relaxing the ring — radius_bias=0 in both red runs, and load_control::radius reduces to the old budget().radius(base) when the bias is 0 (crates/cartopolis/src/systems/map/load_control.rs:152-160). It is not the cell_bundle 404 probe either; that latched once, 0.3 s into the run (crates/cartopolis/src/systems/map/cell_bundle.rs:97-206, and the log's single this host serves no cell bundles line). I have not established the mechanism — that needs a build, which this pass may not do.

The second, older problem the timeout exposed

--wait cannot bound this step, and never could. progress.elapsed += time.delta_secs() uses the virtual clock (crates/cartopolis/src/systems/dev/shot_harness.rs:2514, and the comment at :2517-2520 contrasts it with real on purpose), which Bevy clamps at 0.25 s per frame. --wait 120 is therefore at least 480 frames; at the ~3 s/frame this viewpoint costs on lavapipe that is up to 24 minutes per capture, and --flicker takes two. The 15-minute step ceiling is unreachable by the flag under it. When the scene does not settle early, the runner kills the process and the step's metrics dump — the one thing that would explain the red — never prints.

The green run had 2 m 48 s of headroom on a box shared with nominatim, overpass and every other agent's build. That is not a margin.

Approach

Two parts. Do them in this order; the first is the cause and the second stops the next slow run being opaque.

Part 1 — recover the street-level streaming time (crates/cartopolis).

Measure first, then decide. Reproduce the flicker viewpoint at 1377721 and at its parent dcfa1426, and read fetch_count / fetch_mb / worker_split out of --dump-state for each. Then:

If the extra bytes and the doubled lod22/surfaces job counts are recoverable — i.e. the commit is fetching or meshing cells it did not need to — fix that. Likely places, in the order the evidence points: systems::cell_bundle's interaction with the six per-part loaders it prefills for (crates/cartopolis/src/systems/map/cell_bundle.rs:114-193 — the parts are meant to be read back out of cache, so a loader that re-requests instead would double the fetch), platform::cell_source's unified gate/cache/breaker/request sequence, and lod22's Near/Far build path (crates/cartopolis/src/systems/map/lod22.rs:87-118, :636-698; with LOD22_RADIUS = 2 at :77 and last_door_rank() = 1, a static camera should build each of the 25 cells once, so 50 jobs wants explaining).
If, after that, the remaining cost is the fetch cap doing what it was built to do, do not weaken the cap to suit the CI runner — say so in the commit body with the measurement, and carry the difference in Part 2 instead.

Part 2 — make the gate legible and give it a budget it can meet (.forgejo/workflows/ci.yml, possibly shot_harness).

The step must fail with its metrics rather than being killed silently. The cleanest shape is for the harness to bound a capture in wall clock so --shot exits non-zero with a dump before the runner's deadline; a timeout-minutes raise alone re-buys margin without fixing the silence. Whatever the shape, the step's ceiling and the harness's ceiling have to be stated in terms of each other, and the reasoning goes next to the step in ci.yml like the four constraints already there.

Acceptance criteria

cargo test --locked --workspace --exclude cartopolis_android is green (it already is; this is a regression check, not the fix).
The flicker viewpoint's shot-1 settle wall clock at the branch head is measured and reported against the pre-1377721 baseline of 5 m 53 s on the CI container, and against 1377721's 10 m 04 s.
fetch_mb and fetch_count at that viewpoint are measured at the branch head and compared against 88.2 MB / 332 (green) and 138.5 MB / 356 (red). Either the gap is closed, or the commit body states with the measurement why each remaining megabyte is intended.
The whole Headless flicker smoke (street) step completes inside its timeout-minutes on the CI runner, with margin stated in the commit body — not "it passed once".
A flicker smoke that does not settle exits with a non-zero status and prints /tmp/flicker.json, instead of being killed by the runner with no output. Demonstrate it (e.g. an artificially tiny wall-clock bound locally).
flicker_px at this viewpoint stays under 1500 — the thing the gate is actually for. The green run measured 505 (job 1324) and 461 (job 1319).
cargo fmt --check clean over the five owned crates (big_space excluded, as the gate excludes it).
docs/notes/streaming-order-and-residency.md records what this cost and what was recovered — it is the note 1377721 wrote for exactly this, and the CI wall-clock consequence is a standing fact that belongs in it.
main goes green, and tools/deploy-main's gate (tools/deploy-main:84-92) passes for the resulting sha.

Verification

Cannot be run in this pass — all of these build.

# the suite
cargo test --locked -j 6 --workspace --exclude cartopolis_android

# the failing gate, as CI runs it (needs a client build; ~tens of minutes cold)
CARTO_TILE_URL=https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y} \
WGPU_BACKEND=vulkan cargo run --locked -j 6 -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 A/B, if the mechanism needs bisecting inside 1377721
git stash; git checkout 1377721~1   # dcfa1426, the last green render
# …same command, --dump-state /tmp/flicker_before.json

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

Read fetch_count, fetch_mb, fetch_ttfb_ms, worker_split, draws, frame_ms and settled out of the JSON dumps; take shot-1 wall clock from the gap between the camera placed shot=1 and shot state shot=1 log lines, not from settled_in (that is virtual seconds and does not track wall clock on a slow renderer).

Note on the renderer here. This refinement brief says --shot does not work in this container. The repo's own CLAUDE.md ("How to actually see what the code renders", corrected 2026-08-15) and the headless-shots-run-in-this-container memory both say the opposite — Mesa lavapipe is installed and headless --shot renders. The CI runner's own dumps report software_renderer=true, i.e. the same path. The implementer should try the command; if it fails, the whole of Verification moves to a workstation or the Steam Deck GPU runner, and the timing comparison must then be taken on one machine, since every number above is wall clock on a shared box.

Colour is not evidence here. Whatever else this touches, nothing in this gate may assert on colour, exposure, bloom or lighting — docs/notes/headless-shots-software-renderer.md, and the ci.yml comment at :427-432 says the same.

Out of scope

The grass and palette commits (bc1dfdb, 4e77f8e, 04b9844, b5acac0, 5d2e20b). They are the head of main and the natural suspects, and the numbers clear them: the smoke was already timing out at b5a9c9ad, twelve hours before any of them landed, with identical grass_slots and draws. Their combined cost is frame_ms 2837 → 3031. Do not revert them.
Reverting 1377721 wholesale. Its handset case is real — 991 MB → 371 MB over Groningen — and the commit body says why the five seams landed together. The work is to recover what it cost at street level, not to undo it.
The other two smokes. Headless scene smoke (orbit) and (orbit, phone tier) both passed in the failing run (18.3 s and clean). Leave them alone.
crates/geo's allocation budgets. RENDER_DENSE_ALLOCS was raised to 1,170 in b5acac0 and passes.
The 15-minute ceiling on the orbit steps. They settle in seconds and have never been near it.
main's other red history. Runs 1110/1113/1114/1117 were red for a cargo fmt failure in utils/sun.rs, fixed by b5a9c9ad. That is a separate, already-closed cause.

Open questions

None.

Branch: fix/297-street-smoke-timeout

Original request

The last commit on main that CI ran for is 5d2e20b1, 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 on `5d2e20b1`, but **no test failed**. Every suite in the `test cartopolis` job passed — 912 in `cartopolis`, 251 in `cartopolis_geo`, 108 in `cartopolis_simulator`, plus the rest — and `cargo fmt --check` passed too. The job died because the **`Headless flicker smoke (street)` step hit its wall-clock ceiling** (`.forgejo/workflows/ci.yml:472-487`, `timeout-minutes: 15`). The runner logged `context deadline exceeded` and killed the process; because the step was killed rather than exited, the step's own `|| { cat /tmp/flicker.json }` diagnostic never ran, so the job handed back no metrics at all. The failing job's log is job id `1350` (`GET $FORGEJO_API/repos/$FORGEJO_REPO/actions/jobs/1350/logs`). Note the run-id trap: `actions/runs/723/jobs` resolves `723` as a run **id**, not the run **number** shown in the UI, and returns a different day's job. ### What the smoke actually did | | last green render `dcfa1426`, job 1324, 09-09 18:43 | first red `b5a9c9ad`, job 1331, 09-09 21:21 | this ticket `5d2e20b1`, job 1350, 09-10 11:34 | |---|---|---|---| | shot 1 placed → settled | **5 m 53 s** | 10 m 29 s | 10 m 04 s | | whole step | 12 m 12 s (**passed**, `flicker_px=505`) | timed out | timed out | | `fetch_count` / `fetch_mb` | 332 / 88.2 MB | 365 / 141.1 MB | 356 / 138.5 MB | | `fetch_ttfb_ms` (cumulative) | 36,196 | 74,135 | 73,219 | | `fetch_errors` | 3 | 13 | 13 | | `worker_split` lod22 / surfaces | 25 / 17 | 50 / 26 | 50 / 26 | | `draws` / `frame_ms` | 1275 / 2852 | 1275 / 2837 | 1302 / 3031 | | `grass_slots` | 1,511,680 | 1,511,680 | 2,403,904 | | `radius_bias` | – | 0 | 0 | Two independent readings, one conclusion: 1. **The drawn frame barely moved.** `draws` 1275 → 1302 and `frame_ms` 2837 → 3031 across the whole window. The grass work of `4e77f8e`/`04b9844` (slots 1.51 M → 2.40 M) costs about 7 % of a frame and is **not** what broke this. 2. **The time to stream the street scene doubled**, with no camera or viewpoint change, at one commit. ### The bisect `git log --name-only dcfa142..b5a9c9a` gives exactly one commit that touches the client: **`1377721 perf(map): bound, order and share the per-cell streaming path`** (27 files, +1947/−237). The other two commits in the window are `tools/autopilot.ts` (`b488d29`, `99e942d`), which cannot change a frame, and `b5a9c9a` itself, which rewraps one expression in `crates/cartopolis/src/utils/sun.rs`. `1377721` did not touch the settle test — its `shot_harness.rs` diff only adds the `fetch_outstanding` and `radius_bias` readouts. So the harness is measuring the client honestly; the client got slower. Two things inside that commit are candidates, and they are separable: - **The global fetch cap.** `platform::fetch_gate::capacity()` is `io_threads × 4` floored at 16 (`crates/cartopolis/src/platform/fetch_gate.rs:116-120`, `CAPACITY_PER_IO_THREAD` at `:87`, `FALLBACK_CAPACITY` at `:82`). The CI container reports `map streaming initialized io=4 cpu=7` in **both** the green and red runs, so capacity there is 16 — against the "~55 simultaneous jobs" the commit body says existed before. On a link whose cumulative TTFB for one street scene is 36 s, cutting concurrency by ~3.5× lands directly on wall clock. This part is *deliberate* and exists to protect a handset's 4-thread IO pool. - **More work, not just slower work.** `fetch_mb` 88 → 141 (+60 %), `lod22` worker jobs 25 → 50, `surfaces` 17 → 26. A concurrency cap changes *when* bytes arrive, never *how many*. Something in the commit widened what the street viewpoint streams. It is not `load_control` tightening or relaxing the ring — `radius_bias=0` in both red runs, and `load_control::radius` reduces to the old `budget().radius(base)` when the bias is 0 (`crates/cartopolis/src/systems/map/load_control.rs:152-160`). It is not the `cell_bundle` 404 probe either; that latched once, 0.3 s into the run (`crates/cartopolis/src/systems/map/cell_bundle.rs:97-206`, and the log's single `this host serves no cell bundles` line). **I have not established the mechanism** — that needs a build, which this pass may not do. ### The second, older problem the timeout exposed `--wait` cannot bound this step, and never could. `progress.elapsed += time.delta_secs()` uses the **virtual** clock (`crates/cartopolis/src/systems/dev/shot_harness.rs:2514`, and the comment at `:2517-2520` contrasts it with `real` on purpose), which Bevy clamps at 0.25 s per frame. `--wait 120` is therefore at least 480 frames; at the ~3 s/frame this viewpoint costs on lavapipe that is up to 24 minutes **per capture**, and `--flicker` takes two. The 15-minute step ceiling is unreachable by the flag under it. When the scene does not settle early, the runner kills the process and the step's metrics dump — the one thing that would explain the red — never prints. The green run had 2 m 48 s of headroom on a box shared with nominatim, overpass and every other agent's build. That is not a margin. ## Approach Two parts. Do them in this order; the first is the cause and the second stops the next slow run being opaque. **Part 1 — recover the street-level streaming time (`crates/cartopolis`).** Measure first, then decide. Reproduce the flicker viewpoint at `1377721` and at its parent `dcfa1426`, and read `fetch_count` / `fetch_mb` / `worker_split` out of `--dump-state` for each. Then: - If the extra bytes and the doubled `lod22`/`surfaces` job counts are recoverable — i.e. the commit is fetching or meshing cells it did not need to — fix that. Likely places, in the order the evidence points: `systems::cell_bundle`'s interaction with the six per-part loaders it prefills for (`crates/cartopolis/src/systems/map/cell_bundle.rs:114-193` — the parts are meant to be read back out of cache, so a loader that re-requests instead would double the fetch), `platform::cell_source`'s unified gate/cache/breaker/request sequence, and `lod22`'s `Near`/`Far` build path (`crates/cartopolis/src/systems/map/lod22.rs:87-118`, `:636-698`; with `LOD22_RADIUS = 2` at `:77` and `last_door_rank() = 1`, a static camera should build each of the 25 cells once, so 50 jobs wants explaining). - If, after that, the remaining cost is the fetch cap doing what it was built to do, **do not weaken the cap to suit the CI runner** — say so in the commit body with the measurement, and carry the difference in Part 2 instead. **Part 2 — make the gate legible and give it a budget it can meet (`.forgejo/workflows/ci.yml`, possibly `shot_harness`).** The step must fail with its metrics rather than being killed silently. The cleanest shape is for the harness to bound a capture in **wall clock** so `--shot` exits non-zero with a dump before the runner's deadline; a `timeout-minutes` raise alone re-buys margin without fixing the silence. Whatever the shape, the step's ceiling and the harness's ceiling have to be stated in terms of each other, and the reasoning goes next to the step in `ci.yml` like the four constraints already there. ## Acceptance criteria - [ ] `cargo test --locked --workspace --exclude cartopolis_android` is green (it already is; this is a regression check, not the fix). - [ ] The flicker viewpoint's shot-1 settle wall clock at the branch head is measured and reported against the pre-`1377721` baseline of **5 m 53 s** on the CI container, and against `1377721`'s **10 m 04 s**. - [ ] `fetch_mb` and `fetch_count` at that viewpoint are measured at the branch head and compared against 88.2 MB / 332 (green) and 138.5 MB / 356 (red). Either the gap is closed, or the commit body states with the measurement why each remaining megabyte is intended. - [ ] The whole `Headless flicker smoke (street)` step completes inside its `timeout-minutes` on the CI runner, with margin stated in the commit body — not "it passed once". - [ ] A flicker smoke that does **not** settle exits with a non-zero status and prints `/tmp/flicker.json`, instead of being killed by the runner with no output. Demonstrate it (e.g. an artificially tiny wall-clock bound locally). - [ ] `flicker_px` at this viewpoint stays under 1500 — the thing the gate is actually for. The green run measured 505 (job 1324) and 461 (job 1319). - [ ] `cargo fmt --check` clean over the five owned crates (`big_space` excluded, as the gate excludes it). - [ ] `docs/notes/streaming-order-and-residency.md` records what this cost and what was recovered — it is the note `1377721` wrote for exactly this, and the CI wall-clock consequence is a standing fact that belongs in it. - [ ] `main` goes green, and `tools/deploy-main`'s gate (`tools/deploy-main:84-92`) passes for the resulting sha. ## Verification Cannot be run in this pass — all of these build. ```bash # the suite cargo test --locked -j 6 --workspace --exclude cartopolis_android # the failing gate, as CI runs it (needs a client build; ~tens of minutes cold) CARTO_TILE_URL=https://tiles.cartopolis.org/tiles/osm/{z}/{x}/{y} \ WGPU_BACKEND=vulkan cargo run --locked -j 6 -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 A/B, if the mechanism needs bisecting inside 1377721 git stash; git checkout 1377721~1 # dcfa1426, the last green render # …same command, --dump-state /tmp/flicker_before.json cargo fmt --check -p cartopolis -p cartopolis_core -p cartopolis_geo \ -p cartopolis_simulator -p cartopolis_android ``` Read `fetch_count`, `fetch_mb`, `fetch_ttfb_ms`, `worker_split`, `draws`, `frame_ms` and `settled` out of the JSON dumps; take shot-1 wall clock from the gap between the `camera placed shot=1` and `shot state shot=1` log lines, not from `settled_in` (that is virtual seconds and does not track wall clock on a slow renderer). **Note on the renderer here.** This refinement brief says `--shot` does not work in this container. The repo's own `CLAUDE.md` ("How to actually see what the code renders", corrected 2026-08-15) and the `headless-shots-run-in-this-container` memory both say the opposite — Mesa lavapipe is installed and headless `--shot` renders. The CI runner's own dumps report `software_renderer=true`, i.e. the same path. The implementer should try the command; if it fails, the whole of Verification moves to a workstation or the Steam Deck GPU runner, and the timing comparison must then be taken on **one** machine, since every number above is wall clock on a shared box. **Colour is not evidence here.** Whatever else this touches, nothing in this gate may assert on colour, exposure, bloom or lighting — `docs/notes/headless-shots-software-renderer.md`, and the `ci.yml` comment at `:427-432` says the same. ## Out of scope - **The grass and palette commits** (`bc1dfdb`, `4e77f8e`, `04b9844`, `b5acac0`, `5d2e20b`). They are the head of `main` and the natural suspects, and the numbers clear them: the smoke was already timing out at `b5a9c9ad`, twelve hours before any of them landed, with identical `grass_slots` and `draws`. Their combined cost is `frame_ms` 2837 → 3031. Do not revert them. - **Reverting `1377721` wholesale.** Its handset case is real — 991 MB → 371 MB over Groningen — and the commit body says why the five seams landed together. The work is to recover what it cost at street level, not to undo it. - **The other two smokes.** `Headless scene smoke (orbit)` and `(orbit, phone tier)` both passed in the failing run (18.3 s and clean). Leave them alone. - **`crates/geo`'s allocation budgets.** `RENDER_DENSE_ALLOCS` was raised to 1,170 in `b5acac0` and passes. - **The 15-minute ceiling on the *orbit* steps.** They settle in seconds and have never been near it. - **`main`'s other red history.** Runs 1110/1113/1114/1117 were red for a `cargo fmt` failure in `utils/sun.rs`, fixed by `b5a9c9ad`. That is a separate, already-closed cause. ## Open questions None. --- Branch: `fix/297-street-smoke-timeout` <details><summary>Original request</summary> The last commit on `main` that CI ran for is `5d2e20b1`, 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 12:43:41 +00:00

viberfox-agent added this to the Viberfox project

2026-09-10 12:43:57 +00:00

viberfox-agent commented

2026-09-10 12:44:01 +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 12:54:59 +00:00

viberfox-agent commented

2026-09-10 12:54:59 +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 — 69 turns · $6.36 · session 063af97b-7619-48c1-b7f5-cf0a75a3f004. 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 — 69 turns · $6.36 · session `063af97b-7619-48c1-b7f5-cf0a75a3f004`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:running

and removed

agent:refined

labels

2026-09-10 12:55:00 +00:00

viberfox-agent commented

2026-09-10 12:55:03 +00:00

Author

Collaborator

🤖 Picked this up — working on branch fix/297-street-smoke-timeout 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/297-street-smoke-timeout` 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 referenced this issue from a commit

2026-09-10 13:25:21 +00:00

fix(map): an empty coverage answer is not a reason to rebuild the ring

viberfox-agent referenced this issue from a commit

2026-09-10 13:25:21 +00:00

fix(ci): give the flicker smoke a ceiling in the units its own is written in

viberfox-agent commented

2026-09-10 13:40:03 +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 13:40:03 +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