Consolidate archive sync writers on Bun transactions by mariusvniekerk · Pull Request #1361 · kenn-io/agentsview

mariusvniekerk · 2026-08-07T20:33:06Z

Ordinary sync, full-session replacement, incremental repair, dependent accounting writes, and orphan recovery now share the canonical Bun transaction core. This removes staged commits that could expose mixed session state after a late failure and eliminates hand-maintained common child projections during archive recovery.

SQLite still owns the operations that genuinely depend on its adapter: FTS5 maintenance, pins and physical-ID remapping, ATTACH and temporary-table lifecycle, provenance repair, sanitization, and legacy capability probes. Transcript comparison remains proportional to session history, while changed-row persistence and FTS mutation stay scoped to the affected diff.

Review the atomic session-batch routing, canonical finding helper, and registry-derived orphan-copy boundary.

make test-short remains affected only by the existing macOS FSEvents delivery timeouts; focused sync, full database, DuckDB, and PostgreSQL/activity suites pass.

^{generated by a clanker}

roborev-ci · 2026-08-07T20:54:12Z

roborev: Combined Review (`005ad77`)

Changes requested: one medium-severity reliability issue could leave an incorrect parent unrepaired.

Medium

internal/sync/engine.go:14328 — A successfully written result is no longer queued for its own parent repair. If a later member fails before the final link, or linking itself fails, that session can retain an incorrect parent with no durable retry. After each successful atomic write, queue resultIDs[i], set repairQueued, and then queue its children.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 8m59s

roborev-ci · 2026-08-09T03:55:50Z

roborev: Combined Review (`a37d0df`)

The transaction consolidation is generally sound, but one medium-severity partial-failure issue remains.

Medium

internal/sync/engine.go:14346 — After a member write succeeds, only its spawned children are queued. If a later member fails, the final scoped link at internal/sync/engine.go:14350 is skipped, so the successful member may retain an incorrect parser-derived parent despite an existing spawn edge pointing to it.
- Fix: Durably queue each successfully written resultIDs[i] before continuing, or link each successful member immediately. Add a regression test where an earlier child write succeeds before a later member fails.

Reviewers: 2 done | Synthesis: codex, 11s | Total: 9m27s

roborev-ci · 2026-08-09T04:08:25Z

roborev: Combined Review (`935b4e0`)

The transactional improvements are sound overall, but one medium-severity parent-repair regression remains.

Medium

internal/sync/engine.go:14346 — Successfully committed result sessions are no longer queued for parent repair. If a later member or the final scoped link fails, the function returns before linking those sessions. Because queueWrittenChildren queues only outgoing children, a committed session that is itself a child may retain an incorrect parser-derived parent indefinitely.

Fix: After each successful write, durably queue the result session ID for parent repair and set repairQueued, alongside queuing its children.

Reviewers: 2 done | Synthesis: codex, 23s | Total: 10m2s

roborev-ci · 2026-08-09T04:16:47Z

roborev: Combined Review (`178a8ff`)

Medium-severity issues remain in canonical event indexing and multi-session parent repair.

Medium

Secret findings use incorrect event coordinates — internal/db/messages.go:566, internal/db/session_batch.go:451
Canonical persistence preserves unique, non-positional tool-result EventIndex values, but secret scanning records slice positions. For events indexed 5 and 9, findings record 0 or 1, so SecretFindingSource cannot locate the persisted event and secret reveal fails.
Fix: Derive finding coordinates using the same unique-index/positional-fallback rule as CanonicalMessageRows, and add a persisted scan/reveal regression for non-positional event indices.
Earlier committed sessions can miss authoritative parent repair — internal/sync/engine.go:14332
During a multi-session, single-source sync, successfully committed sessions are not queued for their own parent repair; only their outgoing children are queued. If a later member fails, the early return skips LinkSubagentSessionsForSessions, potentially leaving an earlier committed child with parser-derived rather than authoritative edge-derived parentage.
Fix: Queue each session ID after its atomic write commits, or defer linking all successfully committed IDs. Add coverage for an earlier successful child followed by a failing member.

Reviewers: 2 done | Synthesis: codex, 15s | Total: 9m48s

roborev-ci · 2026-08-09T04:34:16Z

roborev: Combined Review (`e370642`)

Medium-severity issue found: secret findings can reference the wrong result event.

Medium

internal/db/bun_write.go:295 — scanSecretsFromMessages records each result event’s slice position, while canonical writes preserve unique explicit EventIndex values. For example, an event with EventIndex: 7 can produce a finding for index 0, preventing SecretFindingSource from locating or revealing the matched content.
- Fix: Reuse the canonical event-index normalization logic in the secret scanner: preserve unique explicit indices and fall back to slice positions only when indices collide. Add an end-to-end scan/reveal test covering a non-positional index.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 11m25s

roborev-ci · 2026-08-09T15:42:05Z

roborev: Combined Review (`466bcaf`)

Review identified one medium-severity durability issue in deferred spawn-link repair.

Medium

internal/sync/engine.go:14346 — Successful session writes queue only newly spawned children. If the subsequent scoped linking pass fails, a rewritten session whose incoming spawn edge must restore its parent remains committed with parser-derived parentage and no durable repair entry; unrelated future syncs will not repair it.
- Fix: After each successful atomic write, also queue the written result ID and enable the deferred repair pass before scoped linking.

Reviewers: 2 done | Synthesis: codex, 11s | Total: 18m31s

roborev-ci · 2026-08-09T16:28:53Z

roborev: Combined Review (`e09df48`)

The storage refactor is generally sound, but one medium-severity recall-provenance issue remains.

Medium

Recall evidence is not reconciled during append-only writes — internal/db/session_batch.go:464, internal/db/messages.go:644

Newly appended messages or tool calls can duplicate an evidence endpoint, making it ambiguous while the corresponding recall entry incorrectly remains ProvenanceOK.

Suggested fix: Reconcile recall evidence within the same transaction whenever messages are appended, including incremental writes. Add a regression test covering an appended duplicate endpoint.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 19m19s

roborev-ci · 2026-08-09T16:58:32Z

roborev: Combined Review (`96a0984`)

Medium-severity issue found in secret-finding index consistency.

Medium

internal/db/messages.go:599 — The canonical archive path preserves unique non-positional result-event indexes, while secret scanning records slice positions. Because SecretFindingSource queries the persisted index exactly, findings for events indexed like 5 or 9 cannot be revealed or relocated.
- Fix: Share canonical event-index normalization between persistence and scanning, and add a write/scan/reveal test covering distinct non-positional indexes.

Reviewers: 2 done | Synthesis: codex, 11s | Total: 16m45s

roborev-ci · 2026-08-09T17:19:04Z

roborev: Combined Review (`83d74c2`)

Changes need revision due to one medium-severity recall-evidence consistency issue.

Medium

internal/db/messages.go:670 — Recall evidence is reconciled only when new messages are appended. An incremental write may instead change a tool call’s result content or subagent ID through SubagentLinks; because these fields contribute to the recall-evidence digest, link-only writes can leave stale evidence marked as trusted. Reconcile whenever transcriptChanged is true, and add a regression test for a link-only update to a tool call included in trusted evidence.

Reviewers: 2 done | Synthesis: codex, 11s | Total: 12m21s

roborev-ci · 2026-08-09T17:59:00Z

roborev: Combined Review (`7b4ce00`)

Medium-severity risk found in bulk persistence; no security issues identified.

Medium

internal/db/bun_write.go:409 — Canonical message, tool, usage, finding, and repair-ordinal writes pass unbounded slices to single Bun inserts. Large transcripts can produce enormous SQL statements and memory allocations, potentially causing full sync or resync failures. Use bounded row- or byte-sized inserts within the existing transaction.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 12m37s

roborev-ci · 2026-08-09T23:58:36Z

roborev: Combined Review (`43af3ab`)

One medium-severity issue found in snapshot timestamp ordering.

Medium

internal/db/bun_usage.go:1403 — dailyUsageProjectionSnapshotTimestamp omits the SessionCreatedAt fallback used by dailyUsageProjectionTime. Claude rows lacking usage or session-start timestamps can lose chronological ordering during snapshot selection, potentially selecting or attributing usage to the wrong session based on lexical tie-breakers. Fall back to SessionCreatedAt (or format dailyUsageProjectionTime(row)) and add coverage for cross-session snapshots where only creation timestamps establish order.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 11m14s

roborev-ci · 2026-08-10T00:26:21Z

roborev: Combined Review (`00f413d`)

The change is generally sound, but one medium-severity timestamp-ranking inconsistency can produce incorrect recent-edit results.

Medium

internal/db/bun_recent_edits.go:53 — SQLite ranks and paginates edits using julianday, which accepts legacy values such as date-only timestamps that bunmodel.ParseTimestamp later rejects. An invalid timestamp can therefore displace a valid recent edit or select the wrong session, while the returned timestamp is blank.
- Suggested fix: Apply the same strict timestamp-validity rules in the SQL ranking expression, and add a multi-row ordering/pagination test containing both canonical and unsupported timestamps.

Reviewers: 2 done | Synthesis: codex, 11s | Total: 14m16s

roborev-ci · 2026-08-10T00:48:25Z

roborev: Combined Review (`7dc816d`)

Medium-severity batching issue found; no security vulnerabilities were identified.

Medium

internal/db/bun_identity_write.go:328 — Worktree-mapping tombstones are rendered into a single unbounded tuple IN clause. A large publication delta could produce an oversized query and repeatedly block PostgreSQL or DuckDB synchronization. Execute deletions in bounded chunks using canonicalIdentityWriteBatchSize or the canonical byte-budget batching helper.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 11m44s

roborev-ci · 2026-08-10T01:21:03Z

roborev: Combined Review (`c58a4b6`)

Medium-severity performance issue found in the streaming usage path; no security vulnerabilities identified.

Medium

internal/db/bun_usage.go:852 — The streaming usage path counts and preallocates for every raw candidate before applying filters and deduplicating Claude rows. Large archives or narrowly filtered queries may allocate excessive memory and execute two unnecessary full count queries, undermining the streaming design.
- Suggested fix: Remove count-based preallocation or cap it conservatively. Grow results only for accepted rows and buffer only candidates needed for deduplication.

Reviewers: 2 done | Synthesis: codex, 9s | Total: 19m22s

roborev-ci · 2026-08-10T02:05:58Z

roborev: Combined Review (`11a0f2a`)

No issues found.

Reviewers: 2 done | Synthesis: codex | Total: 35m45s

roborev-ci · 2026-08-10T02:43:12Z

roborev: Combined Review (`a305777`)

Medium-severity issue found in tombstone batching; no Critical or High findings.

Medium

internal/db/bun_identity_write.go:328 — Removing the previous 100-key chunking causes every tombstone to be formatted into one unbounded bun.Tuple. Large publication windows may produce excessive SQL and memory use, causing PostgreSQL or DuckDB pushes to fail.
- Fix: Retain bounded batching, preferably using the new payload-budget helper, before constructing each tuple list.

Reviewers: 2 done | Synthesis: codex, 9s | Total: 27m32s

roborev-ci · 2026-08-10T03:02:17Z

roborev: Combined Review (`15f20bb`)

Medium-severity issue found in SQLite usage timestamp handling.

Medium

internal/db/bun_write.go:428, internal/db/bun_usage.go:707 — Archive writes preserve unsupported message timestamps, but SQLite usage queries still validate them with julianday. SQLite accepts values such as 2026-08-09 or 2451545, which bunmodel.Timestamp.Scan then rejects, causing the entire usage report to fail instead of falling back to the session timestamp.
- Fix: Apply the canonical timestamp-availability expression to message usage selection, bounds, and ordering so unsupported values become NULL before typed scanning. Add coverage for a usage-bearing message with a SQLite-valid but noncanonical timestamp.

Reviewers: 2 done | Synthesis: codex, 18s | Total: 14m32s

roborev-ci · 2026-08-10T03:57:18Z

roborev: Combined Review (`f1b0bc9`)

No issues found.

Reviewers: 2 done | Synthesis: codex | Total: 24m40s

roborev-ci · 2026-08-10T16:16:58Z

roborev: Combined Review (`cc7b5be`)

No issues found.

Reviewers: 2 done | Synthesis: codex | Total: 26m55s

roborev-ci · 2026-08-10T18:39:09Z

roborev: Combined Review (`1c707c4`)

No issues found.

Reviewers: 2 done | Synthesis: codex | Total: 22m14s

roborev-ci · 2026-08-11T23:01:51Z

roborev: Combined Review (`82615ca`)

No issues found.

Reviewers: 2 done | Synthesis: codex | Total: 13m15s

roborev-ci · 2026-08-11T23:44:06Z

roborev: Combined Review (`e02f880`)

No Medium, High, or Critical findings; the reviewers found the change clean at the requested severity threshold.

Reviewers: 2 done | Synthesis: codex, 8s | Total: 20m23s

roborev-ci · 2026-08-13T13:42:12Z

roborev: Combined Review (`0ee0579`)

Changes requested: one medium-severity data-version gating issue can leave malformed timestamps unrepaired.

Medium

internal/db/orphaned.go:2104 — Canonical timestamp repair is gated at data version 84 even though version 86 already exists. Archives stamped 84–86 may skip both full resync and orphaned/trashed-row repair, leaving malformed timestamps that strict read paths reject. Bump dataVersion and canonicalTimestampDataVersion to 87 so all previously valid archives are rebuilt and copied rows are canonicalized.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 18m48s

A multi-session source can commit early results before a later member write or final scoped link fails. Queue each committed session itself so deferred repair can restore authoritative incoming-edge parentage instead of only repairing its outgoing children.

Append-only message paths could introduce duplicate evidence endpoints while leaving trusted recall provenance unchanged. Reconcile each affected session inside the message transaction and emit revocation diagnostics only after the write commits.

Bun bulk inserts render an entire model slice as one dialect-aware VALUES statement, so the manual 100-row loops added statement overhead without protecting a driver bind limit. Use Bun's documented slice API throughout canonical writes and keep malformed SQLite timestamps in a one-field archive model extension while strict adapters retain the shared timestamp type.

Secret findings must use the same result-event coordinate that persistence stores or reveal cannot relocate their source. Share the canonical distinct-index and collision-fallback rule between Bun writes and scanning, and cover a non-positional write/scan/reveal round trip.

Late tool results and subagent links change fields included in trusted recall digests even when no message row is appended. Reconcile whenever an incremental write changes transcript content so stale evidence cannot remain trusted.

Bun formats slice inserts into SQL, so unbounded dynamic payloads can create avoidable query and hook working sets even without a driver bind limit. Bound canonical writes by the archive's intentional maximum payload while keeping oversized logical rows intact. SQLite's permissive archive timestamp seam also needs the same canonical availability policy at every shared read boundary. Normalize timing, recent-edit, and content-search hydration, invalidate secret coordinates written before canonical result indexes, and pin PostgreSQL-compatible pricing rounding edges.

The payload estimator runs once per canonical row. Go's reflect.Value.Fields iterator allocates on each struct traversal, doubling bulk-insert allocation counts and pushing archive sync beyond the benchmark gate even though the byte-budget behavior itself was sound. Keep indexed reflection on this hot path and document the targeted modernize suppression so lint cannot rewrite the regression back in.

PostgreSQL rounds TIMESTAMPTZ fractions to microseconds while DuckDB truncates them, so preserving nanoseconds until adapter persistence can move pricing metadata by one microsecond across otherwise identical reports. Apply the existing PostgreSQL half-even rule to canonical pricing rows and revision timestamps before any Bun adapter writes them. Pin the three-backend parity fixture to a fractional timestamp that deterministically exercises the boundary.

SQLite accepts date-only, time-only, and numeric values in julianday even though the canonical Bun timestamp scanner rejects them. Ranking those legacy values before hydration can let an unavailable edit displace a valid file from a bounded page. Use the canonical parser through the SQLite adapter availability seam before recent-edit ranking, while native typed backends keep their existing expression. The regression combines an unsupported future value with a canonical edit so pagination order is observable.

Schema-v11 mirrors can retain timestamps truncated before canonical pricing normalization because timestamp-only differences are intentionally excluded from incremental pricing updates. Advance the disposable mirror boundary so the next push rebuilds and atomically swaps affected files. The upgrade regression simulates the old persisted value and verifies the rebuilt mirror carries the shared half-even microsecond timestamp.

The batch estimator measures static Go row size plus dynamic values before Bun formats SQL. Calling 16 MiB a formatted-query working-set bound overstated what the calculation guarantees because syntax, escaping, and Bun copies add overhead. Describe it consistently as a pre-format payload target while retaining the same byte budget, oversized-row behavior, and transaction boundaries.

Daily usage filtering and Claude snapshot deduplication can discard most raw candidates, so counting every message and usage event first adds two full scans and can reserve memory that the result never uses. Let the accepted result slice grow from the rows that survive streaming. Keep the existing candidate order, filters, and deduplication unchanged.

Removing separate candidate-count scans exposed the normalized usage path to repeated growth and backing-array copies on large archives. Preserve Claude cross-session deduplication with its widened stream, while filtering ordinary messages and usage events in SQL and deriving their allocation capacity from the streaming queries themselves. This keeps the query path unbounded by arbitrary row or bind limits and avoids reintroducing standalone full-table count queries.

Bun formats tuple lists into the SQL statement, so removing the old fixed-row batching left large worktree-mapping publication windows able to build one unbounded query. Apply the canonical pre-format payload budget to tombstone keys so statement growth follows actual string size without reintroducing a guessed row or bind-variable ceiling.

SQLite julianday accepts date-only, time-only, numeric, and some invalid calendar text that the canonical Bun timestamp scanner rejects. Usage projections and bounded queries must classify those message timestamps the same way so they fall back to the session timestamp instead of disappearing or failing during scan. Keep canonical UTC rows on a validated SQLite-native fast path and reserve the exact Go parser UDF for legacy or suspicious text, preserving the usage benchmark allocation profile.

The Windows DuckDB driver converts a scanned time.Time one microsecond below the persisted value, which made the mirror-rebuild contract depend on driver decoding. Assert DuckDB's stored epoch microseconds directly so the test protects canonical pricing precision on every platform.

Timing responses must use the same persisted message IDs as message reads so frontend turn and tool-call joins remain valid. Malformed provider timestamps are repaired at ingestion and during the v84 archive rebuild instead of being tolerated through backend-specific read or fingerprint fallbacks. This keeps SQLite, PostgreSQL, and DuckDB on one strict canonical timestamp contract.

The Bun writer cutover made ID-less parser messages escape and allocated fresh sanitation and canonical-row backing for every session. That pushed cold sync bytes and contributor rebuild allocations over the benchmark gate despite unchanged behavior. Keep per-database schema creation and validation intact. Format canonical timestamps directly into Bun queries, separate target-assigned message conversion from source-ID preservation, and recycle only cleared fixed-row backing bounded by the existing payload budget.

PostgreSQL shortened UTC offsets when shared queries cast canonical timestamps to text, which made strict scans reject valid rows. Keep real timestamp columns typed and type only PostgreSQL's null-only union branches. The allocation-free timestamp appender also cannot receive a typed nil pointer through a direct Bun query argument. Convert that nullable policy value to SQL NULL at the call boundary while preserving value-based timestamp formatting.

DuckDB on Windows can round an RFC3339 string cast one microsecond below the canonical value. That made rebuilt mirrors lose the PostgreSQL-compatible pricing revision even though the shared model had already normalized it. Let DuckDB format canonical Bun timestamps with its typed microsecond literal. Keep SQLite and PostgreSQL on the existing RFC3339 path so archive text remains unchanged.

The data-mode workflow can finish its mapping mutation before the follow-up project inventory reaches the page under CI load. Await both successful responses so the DOM assertion observes the completed user workflow instead of racing the refresh.

Analytics and search planners need one shared relational shape while SQLite, PostgreSQL, and DuckDB retain only the SQL expressions and native sources that differ. Define compositional fragments so Bun keeps query construction and execution ownership, including paired model turns, direct tool facts, timezone projection, lexical ranking, and vector distance/setup seams.

Shared analytics filters must retain the indexed UTC prefilter before exact local-date matching, and usage SQL must use the same activity cutoff as its final reducer. Make the analytics date grain explicit, pass one captured reference time through usage queries, and keep FTS-dependent contract assertions conditional when the optional SQLite module is not compiled.

The unified storage stack must keep archive-scale joins, grouping, windowing, ranking, and limiting inside the database instead of rebuilding backend-specific stores or hydrating full fact sets into Go. Move the remaining analytics panels and activity-report candidate selection onto shared Bun planners while retaining only compact response shaping and content classification in Go.\n\nPreserve paired model ownership, direct tool ownership, exact local date filters, active-duration ranking, and cross-session usage snapshot selection across SQLite, PostgreSQL, and DuckDB.

PostgreSQL must keep native timestamps typed until the shared Bun boundary formats them. Backend-rendered timestamp text violates the strict canonical timestamp contract. Model-filtered output-token aggregates expose their reporting flag as an integer. Match that projection type when ranking sessions, and ignore unavailable timestamps before computing active-duration gaps so database ranking preserves the previous reducer semantics. Generated with Codex (gpt-5.6-sol) Co-authored-by: Codex <codex@openai.com>

roborev-ci · 2026-08-15T02:56:08Z

roborev: Combined Review (`90bd14e`)

Changes need fixes for two medium-severity database issues before merge.

Medium

Duplicate analytics CTE — internal/db/bun_analytics_aggregates.go:191
Velocity queries with a day/hour filter but no model append analytics_scoped_messages twice, causing a duplicate CTE-name SQL error. Give the velocity message set a distinct CTE name and add coverage for time-only velocity filters.
Missing data-version bump for timestamp canonicalization — internal/db/db.go:427, internal/db/orphaned.go:2271
Strict timestamp canonicalization was introduced without advancing dataVersion, while the copy-time cutoff remains 84. Existing version-88 archives therefore skip the necessary resync and can retain malformed timestamps that cause reads, analytics, or replication to fail. Bump dataVersion, align canonicalTimestampDataVersion with it, and test upgrading a version-88 archive containing malformed live and retained-session timestamps.

Reviewers: 2 done | Synthesis: codex, 13s | Total: 30m41s

Bun deprecated its legacy flat-slice IN helper, which caused the stack tip to fail staticcheck. Use the documented List formatter so the pin-remap query keeps the same SQL semantics on every dialect while remaining compatible with the current Bun API.

roborev-ci · 2026-08-15T17:49:58Z

roborev: Combined Review (`a944aac`)

Medium — SQL candidate ranking diverges from SignalCandidates semantics and may produce unstable limited drilldown results.

Medium — internal/db/bun_analytics_signals.go:373: The SQL ranking always prioritizes scored sessions over unscored sessions and lacks a deterministic final tie-breaker. SignalCandidates instead falls back to date whenever either health score is absent, so mixed scored/unscored candidates or ties can change or destabilize results near the limit. Reuse SignalCandidates or reproduce its ranking semantics in SQL, add a stable id tie-breaker, and test mixed-score candidates and ties crossing the result limit.

Reviewers: 2 done | Synthesis: codex, 10s | Total: 26m14s

mariusvniekerk changed the title ~~t3code/bun sync writer unification~~ Consolidate archive sync writers on Bun transactions Aug 7, 2026

mariusvniekerk force-pushed the t3code/bun-sync-writer-unification branch from 005ad77 to a37d0df Compare August 9, 2026 03:46

mariusvniekerk force-pushed the t3code/bun-sync-writer-unification branch from 935b4e0 to 178a8ff Compare August 9, 2026 04:08

mariusvniekerk force-pushed the t3code/bun-sync-writer-unification branch from e02f880 to 0ee0579 Compare August 13, 2026 13:26

mariusvniekerk and others added 25 commits August 14, 2026 22:28

fix(storage): reconcile incremental tool links

9e95603

Late tool results and subagent links change fields included in trusted recall digests even when no message row is appended. Reconcile whenever an incremental write changes transcript content so stale evidence cannot remain trusted.

test(e2e): await data inventory refresh

0e58fb8

The data-mode workflow can finish its mapping mutation before the follow-up project inventory reaches the page under CI load. Await both successful responses so the DOM assertion observes the completed user workflow instead of racing the refresh.

mariusvniekerk force-pushed the t3code/bun-sync-writer-unification branch from fae4c68 to 90bd14e Compare August 15, 2026 02:28

Uh oh!

Conversation

mariusvniekerk commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roborev-ci Bot commented Aug 7, 2026

roborev: Combined Review (005ad77)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (a37d0df)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (935b4e0)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (178a8ff)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (e370642)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (466bcaf)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (e09df48)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (96a0984)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (83d74c2)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (7b4ce00)

Medium

Uh oh!

roborev-ci Bot commented Aug 9, 2026

roborev: Combined Review (43af3ab)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (00f413d)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (7dc816d)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (c58a4b6)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (11a0f2a)

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (a305777)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (15f20bb)

Medium

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (f1b0bc9)

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (cc7b5be)

Uh oh!

roborev-ci Bot commented Aug 10, 2026

roborev: Combined Review (1c707c4)

mariusvniekerk commented Aug 7, 2026 •

edited

Loading

roborev: Combined Review (`005ad77`)

roborev: Combined Review (`a37d0df`)

roborev: Combined Review (`935b4e0`)

roborev: Combined Review (`178a8ff`)

roborev: Combined Review (`e370642`)

roborev: Combined Review (`466bcaf`)

roborev: Combined Review (`e09df48`)

roborev: Combined Review (`96a0984`)

roborev: Combined Review (`83d74c2`)

roborev: Combined Review (`7b4ce00`)

roborev: Combined Review (`43af3ab`)

roborev: Combined Review (`00f413d`)

roborev: Combined Review (`7dc816d`)

roborev: Combined Review (`c58a4b6`)

roborev: Combined Review (`11a0f2a`)

roborev: Combined Review (`a305777`)

roborev: Combined Review (`15f20bb`)

roborev: Combined Review (`f1b0bc9`)

roborev: Combined Review (`cc7b5be`)

roborev: Combined Review (`1c707c4`)

roborev: Combined Review (`82615ca`)

roborev: Combined Review (`e02f880`)

roborev: Combined Review (`0ee0579`)

roborev: Combined Review (`90bd14e`)

roborev: Combined Review (`a944aac`)