{ "assessment": { "decisions": [ { "decided_by": "scorer", "defect_id": null, "finding_id": "f1", "id": "d1", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f2", "id": "d2", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f3", "id": "d3", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f4", "id": "d4", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f5", "id": "d5", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f6", "id": "d6", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f7", "id": "d7", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f8", "id": "d8", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f9", "id": "d9", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f10", "id": "d10", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f11", "id": "d11", "outcome": "rejected", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f12", "id": "d12", "outcome": "rejected", "reason": null }, { "decided_by": "locality", "defect_id": "13", "finding_id": "f13", "id": "d13", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "17", "finding_id": "f14", "id": "d14", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "6", "finding_id": "f15", "id": "d15", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "9", "finding_id": "f16", "id": "d16", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "2", "finding_id": "f17", "id": "d17", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "11", "finding_id": "f18", "id": "d18", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "4", "finding_id": "f19", "id": "d19", "outcome": "matched", "reason": null }, { "decided_by": "locality", "defect_id": "8", "finding_id": "f20", "id": "d20", "outcome": "matched", "reason": null }, { "decided_by": "scorer", "defect_id": null, "finding_id": "f21", "id": "d21", "outcome": "rejected", "reason": null } ], "judge": null, "judged": false, "scorer": { "commit": "10b3b2068100b7ba429855e062500eaf83b90120", "digest": "sha256:a1a935298956020ee6d767a756847abb4c00694c88c2eb80d454886ebc4acf8c", "id": "bench-score", "version": "1" }, "state": "measured" }, "benchmark": { "input_fingerprint": "69301578538a", "key_fingerprint": "bd331c0b144e", "policy_fingerprint": "c53f8cfc8c75", "prompt_fingerprint": "74234e98afe7", "subject": "proxy" }, "build": { "commit": "b0f313c0b59a66ecc7612396dc8db0ea5da13a7a", "digest": null, "dirty": false, "label": "afi 0.30.0", "version": "0.30.0" }, "configuration": { "fingerprint": "5ef3f0fa5235", "label": "default", "models": [ { "effort": "high", "model": "z-ai/glm-5.3", "protocol": null, "provider": "z-ai", "role": "agent" } ], "profile": null, "resolved": { "effort": "high", "instructions": [], "sandbox": { "backend": "macOS Seatbelt", "mode": "read-only", "network": "denied" }, "source": "openrouter", "system_prompt": { "file": null, "mode": "builtin" }, "tools": [ "read_file", "write_file", "edit_file", "list_dir", "search_files", "glob_files", "run_bash", "wait_background" ] } }, "coverage": { "chunks": null, "files_failed": 0, "files_kept": null, "files_skipped": 0, "files_unreviewed": 0, "hunks": null, "state": "measured" }, "evidence": [ { "digest": "sha256:cd014ee6cfe24007f2dac10b61ee1a631aaf8fb3354cf0e97b7531dd13bc0bb1", "media_type": "application/json", "path": "summary.json", "role": "summary" }, { "digest": "sha256:6987723c31483481ac4b4a41aed1033b6821ec8272c90d83b0c47dd8703991e9", "media_type": "application/json", "path": "findings.json", "role": "findings" }, { "digest": "sha256:09a3a4dfef3eb7552759987da57bb85000e8c464702479161f0c118d34b69c65", "media_type": "application/json", "path": "meta.json", "role": "meta" }, { "digest": "sha256:508edb48553b703352bcc2e7a9c9c78387f3818bd815294be2f83892b8b945c7", "media_type": "application/json", "path": "spend.json", "role": "spend" }, { "digest": "sha256:3cb8ab1cda003638c882316f2392ec65a4a16b76fcdffecceaf533f8d0f06c17", "media_type": "application/jsonl", "path": "result.jsonl", "role": "result" }, { "digest": "sha256:38917a124f17b52bf54b00496b847f1dd2a4b78f03e9df8afa18e74d6c56f4ff", "media_type": "text/plain", "path": "stderr.txt", "role": "stderr" }, { "digest": "sha256:2bac43f772bcde5b8b7fbf960153d2254f0f1f5eaf728fc48187895fa4b66703", "media_type": "application/gzip", "path": "afi-home/logs.tar.gz", "role": "traffic" } ], "execution": { "billing_limit_usd": 2.0, "budget_usd": null, "deadline_exceeded": false, "exit_code": 0, "finished_at": "2026-08-31T12:16:50Z", "started_at": "2026-08-31T12:12:37Z", "wall_seconds": 253.0 }, "extensions": { "afi": { "found_per_pass": { "agent": 21 }, "passes": null, "review_seconds": 251.385, "tier1_only": false, "variant_hash": null } }, "findings": { "items": [ { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "says links counted at link size, but `fs::metadata` follows symlinks and returns the *target's* size, not the link's size.\n\n`fs::symlink_metadata` returns the link's own size. So the code contradicts its comment: a symlinked blob is counted at the target's size. Consequence: on a store where blobs are hardlinked (hardlinks don't matter \u2014 metadata is same file, fine) or symlinked from elsewhere, `held` counts target bytes, possibly double-counting... Actually if blobs are symlinked into the store from a shared volume, each blob's metadata is the target's length \u2014 the total counts real bytes, which is arguably what you want for space, but the comment says the opposite (\"counted at the size of the link\"). The consequence per their rationale: the total should be \"the number of bytes this directory is answerable for\" \u2014 with `fs::metadata`, symlink targets' sizes are counted, which for a moved store linked (hardlinked, likely \u2014 moving between volumes uses hardlinks, not symlinks; hardlink metadata len is the file size, so fine). If they meant symlink, metadata follows and gives file size. Hmm: for hardlinks, `fs::metadata` len == file size, correct. The comment says \"A link is counted at the size of the link\" \u2014 for a hardlink, size of link == size of file. So comment makes sense for hardlinks. For symlinks it follows. Is this a defect? If it followed a symlink out of the store... they'd delete a file outside the store? `fs::remove_file` on a symlink removes the symlink only, not the target \u2014 safe. And `meta.is_dir()` following a symlink into a directory outside the store would recurse outside the blob dir \u2014 collect would walk outside the blob directory via a symlinked dir! `fs::metadata` follows symlinks, so a symlink to a directory makes `meta.is_dir()` true and it recurses into it. Consequence: a symlink in the blobs dir pointing elsewhere causes the sweep to walk (and potentially unlink files in) a directory outside the blob store. But would an attacker plant a symlink? The blob store is written only by the proxy... A malicious upstream can't create symlinks (writes bytes). Local operator could. `BlobStore::writer`/commit never creates symlinks. Edge case. I might report as low: `collect` follows symlinks, so a symlinked directory under blobs is walked (and a symlink to a file counts at target size, contradicting the comment). This is a genuine TOCTOU-ish/symlink-traversal defect in code whose only job is filesystem walking. Severity low/medium. Given the deploy described (\"store moved between volumes often has blobs linked into it\") \u2014 if they symlink a directory (e.g. `blobs/sha256/ab/cd` \u2192 old store), the sweep would recurse into the old store and delete blobs there too \u2014 outside `CAIRN_BLOB_DIR`. That's concrete: line 164-168. Medium maybe. I'd rate yellow (medium) or blue (low). I'll say for the symlinked-directory traversal (deletes outside the blob dir), since their own comment anticipates linked stores. Hmm, but is symlinking a directory realistic? Their comment says \"blobs linked into it rather than copied\" \u2014 typical is hardlinks for files. With hardlinks, no traversal. With `cp -al` you get hardlinks. With symlinks (`ln -s`), `fs::metadata` follows. The defect: comment claims one behavior (size of the link), code does another (size of target); and directory symlinks are traversed, letting a sweep unlink files outside the blob directory. I'll report as one finding, medium or low. Let me be precise: lines 160-168.\n\n10. **`forget` race**: index entries removed for digests that were swept; but between `referenced()` and `forget`, a fetch could have just linked an index entry for a digest the sweep decided was unreferenced? No \u2014 if the sweep decided unreferenced, that means at index-read time no entry existed; then a fetch concurrently commits blob + links entry. The blob is deleted (unreferenced at scan time... wait order: index read first, then blob walk. Fetch commit blob at T1 after blob walk already passed that leaf? If blob walk happens after commit, blob seen; index entry written at T2 after index read; sweep deletes blob, then `forget` \u2014 index map was read before T2, so `gone` hex not in map, entry not removed. Left: stale index entry pointing at deleted blob \u2014 handled by resolve (refetch). The request itself fails at open_blob with 500 though. That's finding 3.\n\n11. **admin.rs:73 `reclaim` is sync in async handler** \u2014 same as finding 4; the blocking walk in an async fn without spawn_blocking. Report at admin.rs:76 or sweep.rs:90. I'll report once, pointing at sweep.rs:90 (the function) or admin.rs:76 (the call in async context). Both lines. Policy says name both lines. I'll cite sweep.rs:90 with mention of admin.rs:76 and main.rs:116.", "id": "f1", "locations": [ { "end_line": 163, "path": "sweep.rs", "start_line": 160 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "(COUNTERS order) or 88-97 (values order).\n\nThe changed lines \u2014 diff shows both. I'll cite metrics.rs:94 (where values order diverges from COUNTERS). Actually cite the `values()` return lines 94-95. Severity: high? The metrics are wrong \u2014 blob count and byte count swapped. It misleads operators but doesn't break serving. high.\n\n13. **`held` doesn't include partials**: `Reclaimed.held` is \"Bytes of blob the store held when the sweep started\" \u2014 blobs only; partials counted separately. Doc says fine.\n\n14. **Sweep doesn't count `remaining >= self.max_bytes`**: when `remaining == max_bytes`, it removes \u2014 \"back within ceiling\" means \u2264? `remaining >= max_bytes` removes when exactly at ceiling. Minor semantic: at exactly ceiling it evicts. The docs say \"until the store is back within CAIRN_CACHE_MAX_BYTES\" \u2014 within could include equal. Edge, off-by-one-ish. Not worth reporting.", "id": "f2", "locations": [ { "end_line": 57, "path": "metrics.rs", "start_line": 51 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "if remove fails (error), the code still does `remaining -= size`, `bytes += size`, `removed += 1`, `gone.push(hex)` \u2014 and `forget` then deletes the index entry for a blob that is still on disk!\n\nThat's a real bug: a failed unlink (e.g. EACCES, or on Windows-ish, or a race where the file is open) causes the index entry to be removed, making the blob unreachable garbage that future sweeps will then see as unreferenced and delete. Wait \u2014 future sweep: blob unreferenced \u2192 remove (still failing?) counts it again. Hmm, but more importantly `forget` deletes the index entry even though the blob removal failed. The consequence: the cache entry is dropped while the bytes remain \u2014 a subsequent request refetches (fine, by design), but the bytes leak as unreferenced... until the next sweep removes them as unreferenced. So the leak self-heals next sweep. But also `bytes`/`removed` metrics overstate reclaimed bytes. The `forget` deleting index for a still-present blob: blob then looks unreferenced forever \u2192 next sweep removes it. So consequence: metrics wrong, index entry lost while blob exists (brief inconsistency, next sweep cleans). Medium-low. But is it a defect worth flagging? The comment says failure is \"usually a blob that has already gone\" \u2014 in that case fine. When failure is other (permissions), the code proceeds as if removed: double-counts bytes, removes index entries for a blob still present, and `remaining` decreases as if freed so the ceiling may not actually be enforced (disk still full!). That's the real consequence: on persistent unlink failures, the sweep reports reclaim and reduces `remaining` as if space was freed, so the store can stay over the ceiling while sweep reports success. Concrete: sweep.rs:125-137. Severity medium . Actually the more common failure is NotFound (already gone) where treating as removed is fine except the size accounting was already stale (the blob counted in `held` because the walk saw it). Eh \u2014 NotFound means it went between walk and unlink; counting as removed is harmless-ish. But EACCES etc: real bug. I'd report .", "id": "f3", "locations": [ { "end_line": 137, "path": "sweep.rs", "start_line": 126 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "is factually wrong (\"a fetch that is not coming back\") \u2014 there's no coordination with in-flight writers.\n\nAlso note the store pre-existing comment at store.rs:213-215: \"a fetch that dies halfway - a killed process ... leaves a file in incoming\" \u2014 partials from a killed process have no owner. But live processes' partials are owned. The sweep cannot distinguish. Yes.", "id": "f4", "locations": [ { "end_line": 223, "path": "sweep.rs", "start_line": 220 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "comment shows the authors considered external deleters but not their own sweeper.\n\nI'd say high or medium. The failure: request fails with 500 after having done all the work; client (package manager) will likely error. Probability low per request but nonzero on every sweep. I'll rate medium. Hmm. Between 2, 3 \u2014 both are the same class (sweep vs concurrent fetch races) but distinct windows/mechanisms. I'll report separately: one for partials (clear_partials vs BlobWriter), one for blob walk order (referenced-before-collect vs commit-then-link).\n\nActually, for finding 3 there's an even simpler statement: the sweep reads the index before walking blobs, so a blob committed after the index read but before the blob walk appears unreferenced and is deleted \u2014 including the one a request in flight just committed, whose `open_blob` then fails (cache.rs:90) and the request 500s. And also: even for fully completed entries? No \u2014 entry written before index read \u2192 referenced. Only the in-flight window.\n\nWait, another subtlety for finding 3: the fetch order in cache.rs `fetch()`: commit blob (T1) \u2192 register_version (network, T2) \u2192 link index (T3). So the blob is unreferenced for T1..T3, which includes a registry roundtrip \u2014 easily 50-500ms. If the sweep's `referenced()` read happens in that window and the blob walk sees the blob (walk happens after), deletion. `forget` won't remove the entry (not in map), so the entry gets written at T3 pointing at a deleted blob \u2192 next request refetches (fine). But the current request 500s at open_blob. Consequence concrete.\n\n18. **`.env.example` comment says 32 GiB and value 34359738368** \u2014 32 GiB = 34359738368 bytes. Correct.\n\n19. **docs/operations.md says sweep takes \"the same bearer token as the purge route\"** \u2014 true.\n\n20. **Route method/path**: `POST /v1/admin/cache/sweep` and purge is `DELETE /v1/admin/cache/{digest}`. Conflict? `/v1/admin/cache/sweep` POST vs `/v1/admin/cache/{digest}` DELETE \u2014 different methods, no conflict in axum routing (path match is per-method). A POST to `/v1/admin/cache/sweep`... matches only the sweep route. A DELETE to `/v1/admin/cache/sweep` \u2192 matches purge route with digest=\"sweep\" \u2192 Digest::parse fails \u2192 400. Fine.\n\n21. **`SweepQuery.dry_run` bool deserialization**: `?dry_run=true` \u2192 true. `?dry_run=1`? serde bool from \"1\"? With serde_urlencoded... axum Query uses serde_urlencoded; bool from \"1\" \u2014 serde_urlencoded parses via `FromStr`? Actually serde_urlencoded uses `serde` deserializer where bool expects \"true\"/\"false\". `?dry_run=1` would 400. Minor, not a defect per se. Skip.\n\n22. **Interval task not aborted on shutdown**: spawn_sweeps task runs forever; on graceful shutdown, axum serve returns and main exits \u2014 fine, task dropped. Not a defect. The doc says \"Not part of the graceful shutdown either\" \u2014 deliberate. But note: tokio runtime shuts down when main returns; the sweep task is just dropped mid-unlink \u2014 they say that's fine. OK.", "id": "f5", "locations": [ { "end_line": 96, "path": "cache.rs", "start_line": 90 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "says the mutex is \"Held for the whole of a sweep, so this module's one-at-a-time promise is something the type keeps rather than something every caller remembers\" \u2014 but `sweep()` bypasses it, and\u2026\n\nsays the mutex is \"Held for the whole of a sweep, so this module's one-at-a-time promise is something the type keeps rather than something every caller remembers\" \u2014 but `sweep()` bypasses it, and the admin route calls `sweep()` directly. Two concurrent sweeps over one directory: exactly the scenario the module doc (lines 10-12) warns about (\"Two of them over one directory would each decide what to remove from a total the other is already changing\"). This is a concrete, definite defect: admin.rs:76 calls `sweeper.sweep()` which never locks `running`; sweep.rs:90 `sweep` is `pub` and lock-free while `run` locks. High severity . Wait \u2014 but the sync sweep can't await a tokio Mutex... that's presumably why they split: the route is sync. But they could have made the handler async and used `run()`-style locking or a sync `std::sync::Mutex`, or `try_lock`. As written: concurrent interval sweep + on-demand sweep both walk and delete. Also even two concurrent on-demand POSTs both bypass the lock. This is a strong finding.\n\nLet me double check admin.rs:76: `let reclaimed = app.sweeper.sweep(dry_run);` \u2014 yes, sync `sweep`, no mutex. And sweep.rs:82-85 `run()` takes `self.running.lock().await` then calls `self.sweep(false)`. `sweep` itself doesn't touch `running`. Confirmed.\n\n24. **Interval sweep + on-demand dry_run interplay**: dry run doesn't remove, but it does call `clear_partials(dir, dry_run=true)` \u2014 no removal. OK.", "id": "f6", "locations": [ { "end_line": 67, "path": "sweep.rs", "start_line": 65 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "app.sweeper.run().await` blocks the tokio worker with sync fs walk \u2014 part of finding 4.\n\nThe module doc justifies sync std fs, but running it on the async runtime without spawn_blocking blocks that worker thread for the entire walk. With rt-multi-thread default worker count = cores; one worker blocked is tolerable-ish, but the admin route also blocks a worker per request. And the walk reads every index entry file fully (`fs::read` in referenced()) \u2014 index can be huge. Blocking a worker for minutes. performance.\n\nAlso blocking in the interval loop: while the sweep runs (say 30s), the tick awaits... fine.\n\n26. **`forget` deletes index entries for blobs removed by ceiling-eviction** \u2014 intended (blob gone, entry stale). Fine. But it also deletes entries for blobs whose removal failed (finding 15) and for the \"already gone\" NotFound case \u2014 fine.\n\nBut wait, there's another `forget` issue: index entries for digests removed by an *admin purge* between the index read and blob walk: blob gone \u2192 not in candidates \u2192 no action. Fine.\n\n27. **`gone` includes hex of files that failed to parse file_name?** \u2014 `continue` skips them. Fine.\n\n28. **Reclaimed.partials counted even in dry run as \"removed\"**: in dry_run, `clear_partials` counts files it *would* remove and labels them `partials` \u2014 the struct field says \"Abandoned partial writes it removed\" \u2014 in dry run it didn't remove. Minor semantics; the JSON says \"partials\" which in dry-run means \"would remove\". Consistent with dry-run reporting purpose. Not a defect worth flagging? The docs say dry run \"reports what one would reclaim\". OK.\n\n29. **config validation: `cache_min_age` zero allowed** \u2014 skip as discussed. Hmm, actually let me reconsider: is there an argument it's a bug? `.env.example` documents it as grace period; zero means \"no grace\", and the eviction predicate `age >= min_age` with min_age=0 evicts new blobs under pressure \u2014 could evict a blob whose request is mid-flight after commit (same as race but by design). The code validates the other two new settings but not this one. Inconsistent validation. I'll report as low \ud83d\udd35 maintainability: no zero-check for CAIRN_CACHE_MIN_AGE while its siblings are validated, and zero turns the grace period off so a blob fetched seconds ago can be evicted. Borderline \u2014 but the policy says don't pad. Hmm. I think there's a reasonable case. I'll include as \ud83d\udd35 low, maybe. Let me decide at the end based on confidence. I'd rather include the strongest 6-7 findings. I'll include it as blue.\n\n30. **metrics.rs comment line 31: \"stops a fifth counter\"** \u2014 stale comment (now six counters) \u2014 trivial doc nit, and ironically the order bug proves the comment's point. The line \"Keeping the two side by side is what stops a fifth counter from being rendered under a fourth one's name\" \u2014 it says \"a fifth ... under a fourth one's name\" \u2014 with six counters now the phrasing is stale but harmless. Skip.\n\n31. **The COUNTERS/values order bug** \u2014 double-check carefully: \nCOUNTERS: index 4 = (\"cairn_proxy_sweep_blobs_removed_total\", ...), index 5 = (\"cairn_proxy_sweep_bytes_reclaimed_total\", ...).\nvalues(): index 4 = sweep_bytes_reclaimed.load, index 5 = sweep_blobs_removed.load.\nrender zips \u2192 HELP/TYPE/name from COUNTERS, value from values. So `cairn_proxy_sweep_blobs_removed_total` renders the BYTES value and `cairn_proxy_sweep_bytes_reclaimed_total` renders the BLOB COUNT. Confirmed swapped. Report \ud83d\udfe0 (or \ud83d\udd34?). It's a monitoring correctness bug \u2014 wrong data, no service breakage. \ud83d\udfe0 high.\n\nWhich line to cite? The defect spans COUNTERS (metrics.rs:51-57) and values (metrics.rs:94-95). I'll cite metrics.rs:94.\n\n32. **`.env.example` value**: `CAIRN_CACHE_MAX_BYTES=34359738368` = 32 GiB \u2713.\n\n33. **`collect` on index dir in `referenced()` also uses Candidate with age \u2014 fine.**\n\n34. **Potential unbounded `gone` Vec memory** \u2014 millions of blobs \u2192 gone could be huge (every unreferenced blob). BTreeMap index too. Memory blowup on large stores: `referenced` loads all index entries (file contents) into a BTreeMap> \u2014 for a monorepo dependency cache with hundreds of thousands of entries, that's significant but bounded by store size. The doc says 32GiB ceiling; index entries maybe millions. Memory: each entry path ~100 bytes + digest 64 + vec overhead. 1M entries ~ 200-300MB. Hmm, borderline. Not clearly a defect; skip or low. Skip.\n\n35. **`spawn_sweeps` first tick immediate (finding 7)**: tokio::time::interval \"The first tick completes immediately\". The comment claims \"The fi", "id": "f7", "locations": [ { "end_line": 116, "path": "**main.rs", "start_line": 116 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "vs cache.rs:151-163) \u2014 request 500s.\n\nMaybe ? It's the same class as #2. I'll make it medium (narrower window than #2? Actually #2's window is the entire duration of any in-flight fetch, which is large. #3's window is commit\u2192link which includes a registry roundtrip \u2014 also hundreds of ms per miss. Both plausible. I'll keep #4 as .)\n\n- \ud83d\udfe1 medium:\n - race #4 above (sweep.rs:92 ordering).", "id": "f8", "locations": [ { "end_line": 95, "path": "(sweep.rs", "start_line": 92 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": ".\n\nActually let me reconsider severity: on ENOENT (the \"usual\" case) treating as removed is right. On other errors (EACCES/EIO), remaining decreases without space freed \u2192 repeated sweeps keep \"succeeding\" while disk stays full; index entries deleted \u2192 blobs become unreferenced garbage (cleaned next sweep, again failing...). If unlink persistently fails, blobs become permanently unreferenced (every sweep retries, fails, counts them) and `forget` already removed the index entries \u2014 so cache misses forever while bytes remain. That's a real consequence. .", "id": "f9", "locations": [ { "end_line": 137, "path": "(sweep.rs", "start_line": 125 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "via admin.rs:76 and main.rs:116) \u2014 performance.", "id": "f10", "locations": [ { "end_line": 90, "path": "(sweep.rs", "start_line": 90 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "fs::metadata` follows symlinks, contradicting the comment; a directory symlink under blobs makes the sweep walk and unlink outside the blob dir. or .\n\nThe comment explicitly anticipates linked stores; if those are symlinked, the sweep deletes files outside `CAIRN_BLOB_DIR`. I'll say . Hmm \u2014 but hardlinks (most likely for \"moved between volumes\") are fine, and `fs::metadata` on a hardlink gives file size. The comment says \"A link is counted at the size of the link and not of whatever it points at\" \u2014 for hardlink, size of link = size of file, comment's claim about \"whatever it points at\" doesn't apply (hardlinks don't point). So the comment really describes symlinks, and the code does the opposite for symlinks (follows \u2192 target size). And traversal: symlink-to-dir recurses outside. Concrete mismatch. medium? Given likelihood, low? The stated scenario (store moved between volumes with links) is in their own comment, so the mismatch is real in their anticipated scenario. For file-level symlinks: counted at target size \u2014 if the target is inside the same store (relocated blobs), counting target size is arguably more correct for space, but then `held` counts what... eh. And dir symlink \u2192 traversal outside blob dir + deletion outside. I'll go medium. Hmm, actually let me reconsider: is following symlink into a directory then `remove_file` on entries there dangerous? It deletes files in the symlinked directory \u2014 if operator symlinked `blobs/sha256` \u2192 `/mnt/oldstore/blobs/sha256`, sweep walks /mnt/oldstore and unlinks blobs there. \"Outside the blob dir\" \u2014 but operator symlinked deliberately, so maybe desired. The bigger defect is the comment/code mismatch and unbounded traversal. I'll rate low honestly... no wait. Let me think about who's affected: an operator who follows the codebase's own guidance (comment says linked stores are supported). The sweep would then count sizes wrong (following instead of link size) and possibly evict based on wrong totals. For hardlinks (the common case, `cp -al`), `fs::metadata` is correct (same inode, len = file size) and the comment's \"size of the link\" = file size = correct too. So hardlink case fine. Symlink case: mismatch + traversal. Symlinking a whole tree across volumes is plausible (`ln -s`). Then `held` = target sizes (could be same store, fine-ish), traversal walks the old store, and `remove_file` on old-store blobs \u2014 deleting from the old store, which is... the same blobs. Actually if it's a symlink of the whole blob tree to the old location, deleting through it deletes the same files \u2014 no harm beyond design. Harm case: symlink to something else entirely (not a blob store) \u2014 sweep unlinks arbitrary files there. E.g., operator symlinks one leaf dir to shared storage used by others. Realistic? Meh. I'll rate low: `fs::metadata` follows symlinks so the \"counted at the size of the link\" guarantee in the comment doesn't hold, and a symlinked directory is traversed (and unlinked from) even outside `CAIRN_BLOB_DIR`. Use `symlink_metadata`/`entry.file_type()`. Low-blue.\n\n- \ud83d\udd35 low:\n - first tick fires immediately contradicting comment (main.rs:101/115).", "id": "f11", "locations": [ { "end_line": 168, "path": "(sweep.rs", "start_line": 164 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "explicitly claims the type keeps the promise \"rather than something every caller remembers\" \u2014 and the admin caller bypasses it.\n\nSo yes, the invariant is broken by design of the route. Definitely report. Severity: consequence is two concurrent sweeps \u2192 both compute totals from stale walks \u2192 over-deletion below ceiling + duplicate counting; also concurrent with itself on repeated POSTs. Given the module itself documents why that's harmful, high.\n\nAlso note: even `run()` and `sweep()` interplay: interval task holds lock through whole sweep including sync walk \u2014 while holding the tokio Mutex across a long blocking walk, an on-demand... `run` isn't called by admin. OK.\n\nLet me also double check finding \"clear_partials deletes in-flight fetches\": `incoming` contains `-` temp files. Sweep runs in the same process as in-flight writers. No age check, no exclusion of own pid. Unconditional `fs::remove_file` on every entry. In-flight fetch \u2192 its temp file unlinked \u2192 `commit()`'s rename fails ENOENT \u2192 Error::Storage \u2192 500 to client. Also for `Drop` case irrelevant. Also multi-process: another proxy's in-flight partial \u2014 same problem (their comment acknowledges \"another proxy over the same directory\" for blobs but not partials). Solid \ud83d\udfe0.\n\nWait, actually \u2014 one more check on unlink semantics on Linux: removing the temp file while writer holds it open: writer continues fine, then rename(temp\u2192target) fails because temp path no longer exists \u2192 commit error. Yes.\n\nAnd could the sweep instead remove the file *after* the fetch completes? The window is any fetch in flight during the sweep's `clear_partials` \u2014 with 15-min sweeps and continuous CI fetches, this fires regularly. Also `clear_partials` runs on every sweep including dry-run? Dry-run doesn't remove. But the interval sweep (non-dry) does. High.\n\nAlso the **admin sweep route concurrency**: two POSTs \u2192 two `sweep()` calls concurrently \u2192 both walk. Covered.\n\nNow the ordering-race finding (#4): is it worth reporting separately given clear_partials is already reported? Yes, distinct mechanism/lines.\n\nLet me also reconsider whether `remaining >= self.max_bytes` uses `held` which excludes partials and index \u2014 the ceiling is on blobs only, per config doc \"The most the blob store may hold\" \u2014 blobs only per Reclaimed doc \"Bytes of blob\". Index entries also consume disk but not counted. Ceiling is about blob bytes; index/index-entry bytes uncounted \u2014 minor, skip.\n\nFinal findings list:", "id": "f12", "locations": [ { "end_line": 67, "path": "(sweep.rs", "start_line": 65 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 COUNTERS lists blobs_removed then bytes_reclaimed, values() reads bytes then blobs \u2192 swapped; the two new counters render each other's totals.", "id": "f13", "locations": [ { "end_line": 94, "path": "services/proxy/src/metrics.rs", "start_line": 94 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 clear_partials unlinks every file in incoming unconditionally; a fetch in flight in this process loses its temp file and commit()'s rename fails, 500ing the request (every sweep does this to any\u2026\n\n\u2014 clear_partials unlinks every file in incoming unconditionally; a fetch in flight in this process loses its temp file and commit()'s rename fails, 500ing the request (every sweep does this to any concurrent fetch).", "id": "f14", "locations": [ { "end_line": 232, "path": "services/proxy/src/sweep.rs", "start_line": 232 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 on-demand sweep calls Sweeper::sweep() which never takes the running mutex (sweep.rs:90); concurrent with the interval sweep or another POST, two sweeps walk one store, breaking the one-at-a-time\u2026\n\n\u2014 on-demand sweep calls Sweeper::sweep() which never takes the running mutex (sweep.rs:90); concurrent with the interval sweep or another POST, two sweeps walk one store, breaking the one-at-a-time invariant the module documents.", "id": "f15", "locations": [ { "end_line": 76, "path": "services/proxy/src/routes/admin.rs", "start_line": 76 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 index is read before blobs are walked; a blob committed between the two appears unreferenced and is deleted mid-request, so cache.rs's open_blob fails and the request 500s.", "id": "f16", "locations": [ { "end_line": 92, "path": "services/proxy/src/sweep.rs", "start_line": 92 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 a failed unlink (e.g.\n\nEACCES) is treated as a removal: remaining/bytes/removed advance and forget() drops the index entries, so the sweep reports reclaimed space it did not free and orphans blobs the index no longer names.", "id": "f17", "locations": [ { "end_line": 134, "path": "services/proxy/src/sweep.rs", "start_line": 134 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "performance", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 the synchronous full-tree walk runs inline on a tokio worker (admin.rs:76, main.rs:116) without spawn_blocking; a large store blocks a worker thread for the walk's duration.", "id": "f18", "locations": [ { "end_line": 90, "path": "services/proxy/src/sweep.rs", "start_line": 90 } ], "severity": "performance", "title": "performance" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 fs::metadata follows symlinks, contradicting the adjacent comment (\"counted at the size of the link\"), and a symlinked directory is traversed and unlinked from even outside CAIRN_BLOB_DIR.", "id": "f19", "locations": [ { "end_line": 164, "path": "services/proxy/src/sweep.rs", "start_line": 164 } ], "severity": "bug", "title": "bug" }, { "attributes": { "category": "maintainability", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "\u2014 tokio interval's first tick completes immediately; the comment's claim that the first sweep is one interval away is false, so a fresh proxy sweeps at startup.", "id": "f20", "locations": [ { "end_line": 115, "path": "services/proxy/src/main.rs", "start_line": 115 } ], "severity": "maintainability", "title": "maintainability" }, { "attributes": { "category": "bug", "confidence": null, "evidence_quote": null, "suggested_fix": null }, "body": "(sweep_interval check) missing the min_age sibling.\n\nOr cite 107. I'll cite services/proxy/src/config.rs:131 \u2014 where sweep_interval is validated but cache_min_age is not. Hmm \u2014 is this a defect? Borderline. \"Do not pad.\" The consequence: CAIRN_CACHE_MIN_AGE=0ms accepted \u2192 no grace \u2192 blob evictable the instant it lands. Given the docs emphasize the grace period as protection for pipeline jobs, accepting zero silently... it's a deliberate-ability vs oversight question. I'll include it as blue \u2014 the inconsistency is pointable.\n\nHmm, let me trim: 9 findings, most concrete. Reviewers are compared; quality over quantity but each must be pointable. All are pointable. Keep.\n\nDouble-check line numbers:\n- metrics.rs: values() return block lines 88-97; the swap is at 94-95. Cite 94.\n- sweep.rs:232 is the remove_file in clear_partials. \u2713 (function starts 224).\n- admin.rs:76 `let reclaimed = app.sweeper.sweep(dry_run);` \u2713.\n- sweep.rs:92 `let index = referenced(...)` before 95 collect. \u2713 Cite 92.\n- sweep.rs:134 `remaining = remaining.saturating_sub(candidate.size);` after the error-handled remove at 126. Cite 134 (accounting proceeds regardless of remove outcome at 126). \u2713\n- sweep.rs:90 `pub fn sweep(&self, dry_run: bool)` \u2014 for the blocking-walk finding cite 90. \u2713\n- sweep.rs:164 `let Ok(meta) = fs::metadata(&path)` \u2713.\n- main.rs:115 `ticks.tick().await;` \u2713 (comment at 101-102). Cite 115? The false claim is the comment at 101; the behavior at 115. Policy: name both. One line per finding. I'll cite main.rs:115 and mention the comment. Format only allows one line \u2014 fine, cite 115.\n- config.rs:131-133 for missing min_age check. Cite 131.\n\nSeverity sanity: should metrics swap be \ud83d\udd34? No data loss/service outage \u2014 but it silently corrupts the primary operational signal the docs tell operators to alert on. \ud83d\udfe0 fits.\nShould lock bypass be \ud83d\udfe0? Consequence: over-eviction (extra fetches) and double-reported metrics; no permanent loss. \ud83d\udfe0 ok since it violates a documented core invariant and is trivially triggered (POST twice).\n\nclear_partials race: user-visible 500s during sweeps \u2014 \ud83d\udfe0.\n\nNow write up per format: one line each. Also brief context intro is fine? The format policy says report each defect on one line. I'll keep prose minimal \u2014 maybe a short lead then the lines. Prior guidance says write up findings; the format is the counted part. I'll output just the lines, maybe one intro sentence. Safer: just the lines.\n\nOrder by severity.", "id": "f21", "locations": [ { "end_line": 131, "path": "config.rs", "start_line": 131 } ], "severity": "bug", "title": "bug" } ], "problems": [], "state": "measured" }, "harness": { "adapter": { "digest": "sha256:a1a935298956020ee6d767a756847abb4c00694c88c2eb80d454886ebc4acf8c", "id": "afi", "version": "1" }, "commit": "10b3b2068100b7ba429855e062500eaf83b90120", "digest": "sha256:a1a935298956020ee6d767a756847abb4c00694c88c2eb80d454886ebc4acf8c", "dirty": true, "id": "bench", "repository_url": "https://github.com/smykla-skalski/benchee", "version": "1" }, "incremental": { "carried_count": null, "mode": "not_recorded", "prior_reviewed_sha": null, "reused_tokens": null, "state_source": null }, "label": "glm-5.3", "metrics": { "anchor_max": { "reason": null, "state": "measured", "unit": "count", "value": 3 }, "anchor_median": { "reason": null, "state": "measured", "unit": "count", "value": 0 }, "anchor_missed": { "reason": "no judging pass has looked beyond the scored slack", "state": "not_recorded", "unit": "count", "value": null }, "carried": { "reason": "the reviewer reported no reuse figure", "state": "not_recorded", "unit": "count", "value": null }, "category_defect": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.3076923076923077 }, "category_maintainability": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.0 }, "category_performance": { "reason": null, "state": "measured", "unit": "ratio", "value": 1.0 }, "category_security": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.5 }, "f1": { "reason": "no qualified judge decided these findings, so only locality was measured", "state": "not_applicable", "unit": "ratio", "value": null }, "finding_count": { "reason": null, "state": "measured", "unit": "count", "value": 21 }, "found": { "reason": null, "state": "measured", "unit": "count", "value": 8 }, "intended": { "reason": null, "state": "measured", "unit": "count", "value": 0 }, "judge_bill": { "reason": "no qualified judge decided these findings, so only locality was measured", "state": "not_applicable", "unit": "usd", "value": null }, "missed": { "reason": null, "state": "measured", "unit": "count", "value": 12 }, "precision": { "reason": "no qualified judge decided these findings, so only locality was measured", "state": "not_applicable", "unit": "ratio", "value": null }, "recall": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.4 }, "review_bill": { "reason": null, "state": "measured", "unit": "usd", "value": 0.18321936 }, "seconds": { "reason": null, "state": "measured", "unit": "seconds", "value": 253.0 }, "tier_1": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.3333333333333333 }, "tier_2": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.5714285714285714 }, "tier_3": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.3333333333333333 }, "tier_4": { "reason": null, "state": "measured", "unit": "ratio", "value": 0.25 }, "tokens": { "reason": null, "state": "measured", "unit": "count", "value": 74102 }, "total_bill": { "reason": null, "state": "measured", "unit": "usd", "value": 0.18321936 }, "unkeyed": { "reason": null, "state": "measured", "unit": "count", "value": 13 } }, "producer": { "commit": "10b3b2068100b7ba429855e062500eaf83b90120", "digest": "sha256:a1a935298956020ee6d767a756847abb4c00694c88c2eb80d454886ebc4acf8c", "dirty": true, "id": "benchee", "repository_url": "https://github.com/smykla-skalski/benchee", "version": "1" }, "reviewer": { "id": "afi", "label": "afi review", "repository_url": "https://github.com/smykla-skalski/afi", "tool": { "interface": "cli", "name": "afi" } }, "run_id": "afi/glm-5.3/20260831T111222Z", "runtime": { "architecture": "arm64", "cache_mode": null, "cpus": 14, "memory_bytes": 38654705664, "os": "Darwin", "provider_route": "openrouter", "region": null, "runner_image": null }, "schema": "benchee-run-1", "stamp": "20260831T111222Z", "status": { "reason": null, "state": "completed" }, "target": { "base_sha": null, "diff_digest": "sha256:8b6acd80424c8af9017d7db2e1ceeaca4da5cf1f29e87c3559b2e5ea55782cfe", "pull_request": 8, "repository_url": "https://github.com/smykla-skalski/cairn", "reviewed_sha": "9b51f95ef609a219e211e37b082cd2e6913190e0" }, "usage": { "reason": null, "state": "measured", "value": { "cached_input_tokens": 12096, "input_tokens": 62546, "models": null, "output_tokens": 11556, "reasoning_tokens": 9469, "requests": 3, "stages": [] } } }