fix(node): require Content-Digest on a signed request by beardthelion · Pull Request #306 · Twigpine/node

beardthelion · 2026-08-08T12:38:24Z

Summary

Refuses a signed request that carries no Content-Digest header, and refuses a duplicated covered component in Signature-Input.

Motivation & context

Closes #305

The header was read with a fallback to the empty string. With the header absent, the covered content-digest is empty on both the signing and verifying sides, so verification passes and the body comparison is then skipped for want of a header. A request could carry a body its signature never covered while presenting as validly signed. Every write to a node authenticates this way, so the guarantee a signature is meant to give did not hold for a caller who simply left a header off.

The parser change is smaller: RFC 9421 section 2.1 says a component identifier appears at most once, and a repeat conveys nothing while repeating a line in the signing string a verifier has to build.

Kind of change

Security fix

What changed

gitlawb-node: require_signature returns 400 with a missing_content_digest code when the header is absent, and the body comparison is now unconditional.
gitlawb-core: HttpSignature::parse rejects a repeated covered component.

How a reviewer can verify

cargo test --workspace
cargo test -p gitlawb-node --bin gitlawb-node signed_request_without_content_digest_is_rejected
cargo test -p gitlawb-core parse_rejects_duplicate_components

The first test signs content-digest as the empty string and then sends no header, which is the exact shape that slipped through, and asserts the request is refused before any handler runs. Both tests were checked against an injected revert of the production line they cover, so a regression turns them red rather than leaving them green.

Before you request review

Scope is one logical change; no unrelated churn
cargo test --workspace passes locally
New behavior is covered by tests (required for fixes)
cargo fmt --all and cargo clippy --workspace --all-targets -- -D warnings are clean
Commit titles use Conventional Commits
Docs / .env.example updated if behavior or config changed (or N/A)
Checked existing PRs so this isn't a duplicate

Protocol & signing impact

Touches DID / did:key, Ed25519 / RFC 9421 signatures, UCAN, ref certs, or P2P wire formats
Discussed in an issue before implementation
Backward-compatible with existing nodes and previously signed history

No conforming client regresses. sign_request computes the digest unconditionally and returns it in SignedHeaders, and all eight production call sites attach the header: gl/src/http.rs (three), git-remote-gitlawb/src/main.rs (two), gitlawb-node/src/main.rs, sync.rs, and api/repos.rs. The only paths that omit it are git-remote's unsigned ones, which carry no signature headers at all and are refused earlier. Both changes refuse things a conforming client never sends, so previously signed history is unaffected.

Notes for reviewers

This started life inside #304, the commit status surface, because I found it while making stored status claims re-verifiable. It does not belong there: that feature does not need it, this is a protocol change, and the two want different scrutiny. #304 has been rebased to drop it and now depends on nothing here.

Summary by CodeRabbit

Bug Fixes
- Improved HTTP signature validation by rejecting duplicate, empty, or parameterized signed components.
- Requests using signature authentication must now include a valid Content-Digest header.
- Content digests are consistently checked against request bodies.
- Invalid or missing digest headers now return a clear client error.

require_signature rebuilds the RFC 9421 signing string from the request itself, and it read the Content-Digest header with a .unwrap_or("") fallback. When the header was absent, the covered content-digest component came out as the empty string on both the signing side and the verifying side, so the Ed25519 check passed over a string that committed to nothing about the body. The comparison that would have caught it was guarded on the presence of that same absent header, so it was skipped. The two defects compose: a signed request could carry any body at all, and the handler behind the middleware saw it as authenticated. The header is now required. An absent Content-Digest is a 400 with missing_content_digest, and the digest-versus-body comparison is unconditional, since presence is established before it runs. There is no longer a path through the middleware on which the body goes uncompared. Refusing is safe for every client that already works. sign_request computes the digest with no branch and always returns it in SignedHeaders, and all eight production call sites attach it as a Content-Digest header: the three in gl's HTTP client, the fetch and push requests in git-remote-gitlawb, the node's peer announce, the sync push in sync.rs, and the sync notify in api/repos.rs. So no conforming client regresses. What the refusal removes is the case where a caller signed an empty digest and sent a body no signature covered. HttpSignature::parse now also refuses a covered component that appears more than once, per RFC 9421 section 2.1. A repeated identifier says nothing the single one did not, and it lengthens the signing string a verifier has to build from a list the caller chooses.

coderabbitai · 2026-08-08T12:38:43Z

No actionable comments were generated in the recent review.

Walkthrough

The change tightens HTTP signature validation. Invalid covered components and duplicates are rejected during parsing. Signed requests without a valid Content-Digest header are rejected before handler execution, and present digests are checked against the request body.

Changes: HTTP signature validation

Layer / File(s)	Summary
Reject invalid signature components `crates/gitlawb-core/src/http_sig.rs`	`HttpSignature::parse` accepts quoted bare component identifiers and rejects empty, parameterized, unquoted, unterminated, or duplicate components. Tests cover these cases and large distinct component lists.
Require Content-Digest verification `crates/gitlawb-node/src/auth/mod.rs`	Signed requests require a valid `Content-Digest` header. The middleware always compares the digest with the request body and rejects missing digests before calling the handler.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: kevincodex1

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant require_signature
  participant RequestBody
  participant Handler
  Client->>require_signature: Send signed request
  require_signature->>RequestBody: Verify Content-Digest
  require_signature->>Handler: Forward validated request

Merge Risk: Minimal · up to 25721

The change rejects signed requests without a Content-Digest header and duplicate signature components; no actionable merge-blocking risk remains based on the supplied evidence.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the primary security fix: requiring Content-Digest for signed node requests. It does not mention duplicate component rejection, but a title need not cover every change.
Description check	✅ Passed	The description is complete and follows the repository template. It explains the security issue, lists both changes, identifies issue `#305`, provides verification commands, records completed checks, an…
Linked Issues check	✅ Passed	The changes satisfy issue `#305`. Signed requests without Content-Digest now receive HTTP 400 with missing_content_digest, body verification is unconditional, and duplicate covered components are reject…
Out of Scope Changes check	✅ Passed	The changes remain focused on HTTP signature validation and the linked security objectives. The additional rejection of empty or parameterized components is related parser validation and does not intr…
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 1 files.

Full details: Description check

Explanation

The description is complete and follows the repository template. It explains the security issue, lists both changes, identifies issue #305, provides verification commands, records completed checks, and documents protocol compatibility.

Full details: Linked Issues check

Explanation

The changes satisfy issue #305. Signed requests without Content-Digest now receive HTTP 400 with missing_content_digest, body verification is unconditional, and duplicate covered components are rejected. The separate panic in issue #348 is explicitly outside this PR.

Full details: Out of Scope Changes check

Explanation

The changes remain focused on HTTP signature validation and the linked security objectives. The additional rejection of empty or parameterized components is related parser validation and does not introduce unrelated functionality.

Finishing Touches

Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/require-content-digest-on-signed-requests

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: `5497ab30-e8ed-4897-a400-0248e0d828ab`

📥 Commits

Reviewing files that changed from the base of the PR and between `9a2eac3` and `2572169`.

📒 Files selected for processing (1)

`crates/gitlawb-core/src/http_sig.rs`

Included review availability: 4 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour.

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/gitlawb-core/src/http_sig.rs`:
- Around line 76-86: The HttpSignature::parse component validation must handle
parameterized component identifiers consistently instead of comparing raw text
while later methods only support bare names. Either reject any component
parameters during parsing, or normalize and preserve them through
missing_components() and build_signing_string(); also add coverage proving
reordered equivalent parameters cannot bypass duplicate detection.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 617ccfde-796b-48d3-be02-77351de052b9

📥 Commits

Reviewing files that changed from the base of the PR and between fdf716d and 9a2eac3.

📒 Files selected for processing (2)

crates/gitlawb-core/src/http_sig.rs
crates/gitlawb-node/src/auth/mod.rs

jatmn

I found issues that need to be addressed before this is ready.

Findings

[P1] Make duplicate-component validation linear
crates/gitlawb-core/src/http_sig.rs:79
This scans the remaining component list for every component. An unauthenticated caller can send a Signature-Input with many distinct quoted components, so the new check performs quadratic string comparisons before timestamp, key, required-component, or signature validation rejects it. This server uses Axum/Hyper's default HTTP/1 configuration and does not set a tighter header buffer limit (Hyper permits roughly 417 KiB by default), enough for tens of thousands of short component tokens and billions of comparisons. optional_signature routes invoke this path whenever either signature header is present, including public read routes without an IP limiter, allowing repeated header-only requests to monopolize worker CPU. Track seen components in a HashSet (or enforce a strict component count) and add coverage for a long distinct-component list.

beardthelion · 2026-08-15T15:28:32Z

Heads-up while this is open, since it touches http_sig.rs: HttpSignature::parse has a live panic on attacker-controlled input, now filed as #348.

crates/gitlawb-core/src/http_sig.rs:60-67 finds ( and ) independently and then slices &rest[open + 1..close], so a Signature-Input where ) precedes ( reverses the range and panics. Every other malformed shape in that function returns a typed Error that the caller renders as a 400; this one class walks past it. It is reachable pre-auth, because auth/mod.rs:88 parses before any key is resolved and optional_signature delegates whenever signature headers are merely present.

This PR's diff does not touch that indexing (it adds parse_rejects_duplicate_components around parse but leaves the find/slice lines alone), so the panic survives the merge either way. Flagging it here only so it is visible to whoever lands first: #306 and #261 both touch this file, and the fix in #348 is a single open < close comparison, so it is worth deciding deliberately whether it rides along with one of these or goes separately rather than having all three collide.

Use a HashSet for covered-component duplicate detection so hostile Signature-Input headers cannot force quadratic work before rejection. Reject RFC 9421 component parameters during parse since only bare names are supported end to end.

beardthelion · 2026-08-28T04:39:32Z

Addressed both review items on 2572169.

Duplicate-component validation now tracks seen bare names in a HashSet instead of scanning the tail slice per entry. Revert-check: restoring the old loop made parse_many_distinct_components_completes_quickly fail at 2.84s on a 20k-component header; the HashSet path finishes in under 0.1s.

Parameterized component identifiers are rejected at parse (component parameters are not supported on '…'). Gitlawb only supports bare @method, @path, and content-digest end to end, so this closes the reordered-parameter duplicate bypass without accepting forms missing_components() cannot handle. Added tests for parameterized and reordered-parameter inputs.

cargo test -p gitlawb-core http_sig:: (19/19) and signed_request_without_content_digest_is_rejected still green.

jatmn

LGTM

…e#26 split 1/4) This is the handler-level half of Split PR 1. The previous commit added the migration and the DB methods; this one threads them through crates/gitlawb-node/src/api/repos.rs:2007 (git_receive_pack), the cert issuer, and the startup drain. CHANGES IN THE HANDLER ====================== In git_receive_pack, AT THE LAST POSSIBLE MOMENT before the smart_http::receive_pack call, the handler now: 1. Generates a per-handler request_id (UUID). 2. Captures the raw Signature, Signature-Input, and Content-Digest headers from the request. 3. Calls db.insert_pending_ref_transitions(request_id, ...) which writes one row per ref update in state 'prepared'. The receive_pack call runs as before. After it returns: 4. On Ok: db.mark_pending_ref_transitions_applied(request_id) — the row is the ONLY thing that promotes a 'prepared' row to 'applied', and the drain reads only 'applied' rows. A process crash before this call leaves the row in 'prepared', which the drain never promotes. 5. On Err: db.mark_pending_ref_transitions_cancelled(request_id) — a failed receive_pack leaves the row in 'cancelled', which the drain never promotes. This is what closes the reviewer's two proofs: Proof 1 (crash window): if the process dies after mark_pending_ref_transitions_applied but before the bookkeeping writes, the row is in 'applied' and the next startup drain re-derives the push event, the per-ref certificate (carrying the ORIGINAL pusher DID, not a placeholder), and the anchor handoff. The drain uses the persisted authentic pusher DID and signature header, not a recovered placeholder. Proof 2 (failed receive-pack): the row is only ever flipped to 'applied' in the explicit Ok branch above. A 'prepared' or 'cancelled' row is invisible to the drain, so a failed or dropped receive_pack cannot turn a prepared intent into completed accounting or anchoring. BOOKKEEPING IS NOW DETERMINISTIC-ID =================================== The post-Ok bookkeeping at api/repos.rs:2448 now uses: - record_push_with_id with push_event_id_for(request_id, first_ref) — ON CONFLICT (id) DO NOTHING, so a recovery re-pass is a no-op. - issue_ref_certificate_idempotent with ref_cert_id_for(request_id, ref_name) — ON CONFLICT (repo_id, ref_name) DO NOTHING, returns None if a live-path cert already exists. - insert_anchor_job_idempotent with anchor_job_id_for(repo_id, ref_name, old_sha, new_sha) — the per-transition tuple key, so two pushes to the same ref produce one anchor upload per landed state. The legacy entry points (record_push, issue_ref_certificate, insert_ref_certificate) remain for callers that prefer a fresh UUID per cert; they are #[allow(dead_code)] for the PR 3 cert/CLI compat pass to decide whether to keep or remove. STARTUP DRAIN ============= crates/gitlawb-node/src/main.rs calls durable_outbox::drain_pending_ref_transitions(state, 1000) ONCE before serving, after migrations and after the existing peer / quarantine prunes. Non-fatal: a transient drain failure logs and leaves the rows for the next startup. durable_outbox::drain_pending_ref_transitions reads every 'applied' row, calls derive_one (which re-derives the three artifacts using the persisted authentic pusher DID and signature header), then deletes the row. A second drain pass is a no-op for both the artifacts (idempotent inserts) and the row (gone after the first pass). NEW END-TO-END TESTS ==================== crates/gitlawb-node/src/durable_outbox.rs adds three end-to-end tests in drain_tests, complementing the eight DB-layer tests in db::pending_ref_transition_tests: - drain_re_derives_all_three_artifacts_for_an_applied_row: the reviewer's first proof. Inserts a row in 'applied' state (the crash window), drains, asserts exactly one push event row, exactly one cert row carrying the original pusher DID (not a placeholder), and exactly one anchor job row. Asserts the deterministic cert id matches. Asserts a second drain pass is a no-op. - cancelled_row_produces_no_artifacts: the reviewer's second proof for the cancelled state. A row in 'cancelled' (receive_pack returned Err) is invisible to the drain. - prepared_row_produces_no_artifacts: the reviewer's second proof for the prepared state. A row in 'prepared' (handler crashed between insert_prepared and the post-Ok branch) is invisible to the drain. Each test names the invariant it pins and the production line it covers. Reverting that line turns the named assertion red. Compiles clean, 1099 tests pass with 0 regressions, clippy clean under -D warnings, fmt clean. Cross-PR overlap (declared in the PR description): - Twigpine#134 (anchors auth): composes. The /arweave/anchors route already requires auth; this PR does not change the route. - Twigpine#285 (advisory-lock session affinity): composes. The durable intent is written inside the same handler that holds the lock from Twigpine#285; no changes to the lock layer. - Twigpine#306 (Content-Digest on signed requests): composes. PR 1 persists the Content-Digest header that Twigpine#306 makes mandatory. - Twigpine#314 (small-order Ed25519): independent. PR 1's tests use strong keys. - Twigpine#324 (libp2p keypair persistence): independent. PR 1 does not touch p2p identity. - Twigpine#325 (gossip ref-update auth): independent. PR 1's signed envelope is the HTTP-side equivalent, not the gossip-side. - Twigpine#382 (replication withheld-subtree trees): independent. PR 1 does not touch replication or pin selection.

A claim is provenance, so the signature stored beside it has to reach the bytes stored beside it. It did not. The signing string covers the body only through a content-digest line, and require_signature rebuilds the covered values from the request: with no Content-Digest header the covered digest is the empty string on the signing side and the verifying side alike, the Ed25519 check passes over method, path and nothing else, and the digest-versus-body comparison was skipped for want of a header. An owner could sign that once and post any body under it. The row that produced carried a valid signature, a signing string that verifies under the owner's key, and a request_body the signing string says nothing about — history nobody can re-verify, which is the one thing the row is for. The write path now recomputes the digest of the bytes it is about to persist and requires the signing string to carry exactly that line, which is the write-time form of the check re_verify already ran against a stored row. Line-exact rather than a substring search: build_signing_string emits one component per line, and a contains would also be satisfied by the digest appearing inside another component's value. This is deliberately not the only line of defence, and deliberately not the middleware's. PR #306 requires the header in require_signature and closes the same hole one layer earlier for every signed route; that belongs there, because no other route's correctness should depend on this handler. Neither substitutes for the other. Without #306 the empty digest is still accepted everywhere else; without this, a later relaxation of the middleware resumes writing unverifiable history in silence. Nothing here touches require_signature, so the two do not collide. The route's advertised 8 KiB body bound was also a bound on what gets stored rather than on what gets buffered: require_signature collects and hashes the whole body before any handler runs, so by the time the handler measured it the allocation had happened, and concurrent requests multiplied exactly the cost the number was written to prevent. A RequestBodyLimitLayer now carries the same figure at the transport, outside the auth layers and inside the rate limiters, matching the shape the git routes already use. The handler keeps its own check: it is the one that holds for a handler reached by any other route table. The hand-injected test material had to become coherent with the request it rides on, because a stand-in built over other bytes now takes every bare-router test down the refusal branch. It is built from the body it accompanies and carries a real content-digest line.

beardthelion · 2026-09-07T22:30:13Z

@kevincodex1 LGTM

euxarist

Closes a real hole: at HEAD an absent Content-Digest signs the empty digest and the comparison is skipped entirely, so a signed request could carry an uncovered body. Requiring the header, making the comparison unconditional, and rejecting parameterized/duplicate covered components (necessary for duplicate detection to be sound at all) with a 20k-component linearity probe is thorough, and all eight production sign_request sites attach the header so no conforming client regresses.

… 2/4) (Twigpine#524) * fix(node): ANS-104 transport, three-outcome probe, verify endpoint (Twigpine#26 split 2/4) Reviewer 2 closed PR Twigpine#224 on 2026-08-28 with a directive: split into four narrow PRs. This is Split PR 2 (Arweave transport and verification). The P1 finding the reviewer assigned to this split: the legacy `anchor_item_present` mapped `BAD_REQUEST` and `GONE` to `Ok(false)`, and the recovery code interpreted false as permission to reclaim the row and pay for another upload. Neither 400 nor 410 proves a previously paid item was never accepted: 410 can describe an artifact that existed but is no longer served, and 400 can be produced by gateway, proxy, or routing failure. The concrete failure sequence the reviewer named: bundler accepts the item, the response or terminal DB write is lost, recovery probes the persisted item_id, the gateway returns 400 or 410, and the node pays for a second immutable item for the same transition. Fix: model the probe result as three outcomes, and authorize a re-upload only on a trustworthy, protocol-defined absence. NEW MODULE crates/gitlawb-node/src/ans104.rs - DataItem: the on-wire ANS-104 shape (signature, owner, target, anchor, tags, data — all base64url-encoded except target/anchor). - deep_hash: the canonical signing input per the spec. The signature is over a SHA-256 mix of the dataitem/list/map discriminators, the signature type, owner, target, anchor, the recursively-hashed tag list, and the data payload. A hand-rolled sha256 of the JSON body would produce a hash no Arweave gateway would recognize; the deep-hash is the only correct form. - sign_data_item: Ed25519 over deep_hash. - verify_data_item: parses the owner, checks the signature against an expected pubkey, and reports a specific failure reason on each branch. - 7 unit tests covering round-trip, flipped signature, wrong expected key, mutated data, wire-shape round-trip, deep-hash stability, and the empty-tags edge case. NEW MODULE crates/gitlawb-node/src/arweave_v2.rs - ProbeOutcome: Present (2xx, body parses as ANS-104, sig verifies), DefinitivelyAbsent (404 with a known JSON body shape), Indeterminate (everything else). The reviewer's three-outcome model. - ProbeOutcome::permits_reupload: the recovery policy. ONLY DefinitivelyAbsent authorizes a paid re-upload. Indeterminate keeps the outbox non-terminal; Present skips re-payment. - probe_anchor_item: the gateway probe. 2xx bound to a different item id is Indeterminate, not Present. 2xx with a body that does not parse as ANS-104 is Indeterminate. Oversized bodies are Indeterminate (defense against body-stuffing). - read_capped_body: enforces PROBE_MAX_BODY_BYTES (1 MiB) on the full body, with a Content-Length fast-path that rejects before reading. - verify_anchor: the full path the public verify endpoint takes. Fetches the data item, parses it, verifies the Ed25519 signature against the persisted node_did, decodes the data payload as JSON, and reports the result. - 15 unit tests pinning each classification boundary: 400/410/5xx/transport/2xx-non-json/2xx-bad-sig/2xx-different- owner are all Indeterminate; 404 with empty or known-JSON body is DefinitivelyAbsent; 2xx with a valid signed item is Present; the re-upload policy is exhaustive. NEW DB METHOD crates/gitlawb-node/src/db/mod.rs - get_arweave_anchor_by_item_id: looks up an existing arweave_anchors row by its id (which is the Irys tx id, the same value the Arweave gateway uses to serve the data item). Used by the public verify endpoint to fetch the persisted node_did so the envelope signature can be verified against it. NEW CONFIG crates/gitlawb-node/src/config.rs - GITLAWB_ARWEAVE_GATEWAY_URL: the Arweave gateway the probe reads from. Defaults to https://arweave.net; operators can point it at a private mirror. NEW HTTP ENDPOINT crates/gitlawb-node/src/api/arweave.rs - GET /api/v1/arweave/anchors/verify/{item_id}: the public verify endpoint. Returns {item_id, status, verified, owner_did, data_payload, error} where status is one of "verified" / "definitively_absent" / "indeterminate". - 3 endpoint-level tests covering the verified, 404, and 400 shapes via the live router, asserting the public surface surfaces the three outcomes. WIRE-UP crates/gitlawb-node/src/server.rs - The verify route is registered alongside the existing /api/v1/arweave/anchors list route. NOT IN THIS SLICE (the bundler upload, the next commit): - The handler that builds a DataItem from a ref-cert and POSTs it to the bundler is not in this PR. The ANS-104 module is ready to be called by it; the cert/push-event flow in PR 1 persists the row that the bundler upload would consume. - PR 1's recovery drain produces an `anchor_jobs` row keyed on the (repo, ref, old, new) tuple; the next slice reads that row, builds the ANS-104 data item, POSTs to the bundler, and writes the resulting tx id to arweave_anchors. Compiles clean, 1113 tests pass with 0 regressions, clippy clean under -D warnings, fmt clean. Cross-PR overlap (declared in the PR description): - Twigpine#134 (anchors auth): composes. The verify endpoint reads from arweave_anchors; Twigpine#134's auth layer applies unchanged. The probe model is server-side and unauthenticated by design. - Twigpine#285 (advisory-lock session affinity): independent. The probe is read-only. - Twigpine#306 (Content-Digest on signed requests): independent. The probe does not sign requests. - Twigpine#314 (small-order Ed25519): composes. The verify path calls Did::to_verifying_key which already enforces the small-order check from Twigpine#314. - Twigpine#324 (libp2p keypair persistence): independent. - Twigpine#325 (gossip ref-update auth): independent. The verify path is for the public Arweave gateway, not gossip. - Twigpine#382 (replication withheld-subtree trees): independent. * fix(node): address reviewer findings on Twigpine#26 split 2/4 (transport) - P1 (DB lookup): get_arweave_anchor_by_item_id now filters on irys_tx_id (the externally-routable item id) rather than the internal UUID primary key. The production writer stores a fresh UUID in `id` and the Irys response / ANS-104 derived id in `irys_tx_id`; the old filter would always 404. New integration tests exercise the production writer path with distinct values for the two columns. - P1 (verify-gate): verify_anchor now gates on repo read via authorize_repo_read. The route is split in server.rs: the public list_anchors stays ungated (Twigpine#134 tracks that surface), the verify route gets optional_signature per the team memory `axum-layer-vs-merge-pitfall.md`. Denials on row-lookup, gate, and missing repo all collapse to the same opaque 404 so the public endpoint does not leak anchor-row existence. - P1 (ANS-104 deep-hash): rewritten to the verified SHA-384 recursive list/blob algorithm (matches `arbundles` JS reference). deep_hash returns [u8; 48]; signature is over the raw 48-byte digest. Three reference vectors from `Irys-xyz/arbundles/src/__tests__/deepHash.spec.ts` are bit-exact-asserted as the interop canary per the team memory `self-roundtrip-tests-do-not-prove-interop.md`. - P1 (artifact-identity): v2 verify now derives the protocol id via DataItem::id() (base64url(SHA256(signature))) and requires equality with the requested URL item_id. A node key signs many data items, so a valid signature only proves who signed the response — not that the served item is the one the caller asked to verify. The team memory `verify-against-artifact-id-not-signer.md` is the policy. - P1 (verifier can't read this head's writes): verify_anchor now accepts BOTH the v2 ANS-104 format and the v1 raw-JSON shape the live path on this branch actually writes. The v1 path does a field-equality check on repo, ref_name, old_sha, new_sha, node_did against the persisted row (no signature in v1; Irys storage plus the JSON parse are the integrity guarantee). - P2 (ProbeOutcome in result): AnchorVerifyResult now carries outcome: ProbeOutcome. The HTTP handler maps the structured field to the status string instead of parsing the human- readable error message — any future wording change in arweave_v2.rs can no longer silently reclassify a DefinitivelyAbsent as Indeterminate. - P2 (empty 404 body): classify_404 returns Indeterminate for bodyless 404s. The team memory `distinguish-unknown-from-empty.md` is the policy: a bodyless 404 from a proxy is not a proof of absence, and the recovery policy (permits_reupload -> true on DefinitivelyAbsent) authorizes a paid, irreversible re-upload. - P2 (streaming cap): read_capped_body no longer uses resp.bytes() (which buffers the full response before checking size). It now reads chunk-by-chunk and aborts the moment the cumulative byte count crosses the cap, so a chunked response without Content-Length cannot force unbounded allocation. * fix(node): address three reviewer findings on Twigpine#26 split 2/4 (round 2) * fix(node): address five reviewer findings on Twigpine#26 split 2/4 (round 3) * fix(node): address reviewers round-4 on Twigpine#26 split 2/4 (interop) * fix(node): address coderabbit on Twigpine#26 split 2/4 (raw tags, vint overflow, golden key) * fix(node): enforce artifact-id in probe_item on Twigpine#26 split 2/4 * fix(node): require expected owner for probe Present on Twigpine#26 split 2/4 * fix(node): narrow Twigpine#26 split 2/4 to codec and policy types * fix(node): silence dead-code for deferred slice API on Twigpine#26 split 2/4 * fix(node): doc and bounds-check cleanup in ans104 on Twigpine#26 split 2/4 * docs(node): point tests doc at Ed25519 golden script on Twigpine#26 split 2/4 * fix(node): strict owner lengths, sign-before-hash on Twigpine#26 split 2/4 * fix(node): keep ans104 tags and field widths consistent on hash and encode DataItem keeps both the decoded `tags` and the original Avro `raw_tags`, both public. After a parse, changing `tags` left deep_hash and verify_data_item using the stale raw bytes, and to_binary wrote a header tag count that no longer matched the payload, so the frame failed to parse back. Take the tag block for hashing and encoding from one helper that decodes `raw_tags` and requires it to equal `tags`, and fail closed otherwise. The header count comes from the same validated pairs. Parsed multi-block and size-prefixed items still re-encode byte-exact and keep their signatures. deep_hash now also rejects a non-empty target or anchor that is not 32 bytes, as to_binary already does, so sign_data_item fails instead of signing an item that cannot be encoded. The legacy non-base64url anchor fallback is kept. The module and signature-type docs now say binary parsing accepts sigtypes 1 to 4 while signing and verifying are Ed25519 only on this slice. * build(scripts): declare the golden script's direct npm dependencies ans104_golden_ed25519.mjs imports bs58, @noble/ed25519 and base64url, and ans104_golden.mjs imports base64url, but package.json listed only arbundles, so they resolved only through hoisting. Declare them at the versions already locked, update the lockfile root entry (no resolved version or hash changes), and note the regeneration command in the golden output file. --------- Co-authored-by: Gravirei <gravirei@users.noreply.github.com>

…plit 3/4) (Twigpine#548) * fix(node): version ref_certificates for forward compat (Twigpine#26 split 3/4) Reviewer 2 closed PR Twigpine#224 on 2026-08-28 with a directive: split into four narrow PRs. This is Split PR 3 (certificate / CLI compatibility). No findings are assigned to it; it is required because the protocol/client work is independently reviewable and should not remain coupled to post-receive recovery. The wire-format problem: the ref-cert payload is a fixed 7-field JSON blob the node signs. Future changes (additional pusher attestations, content-binding fields, secondary signatures) would either break every existing cert or be impossible to ship without a flag day. Versioning the cert makes the format forward-compat and explicit. NEW MIGRATION v28 ref_certificates gains `version INTEGER NOT NULL DEFAULT 1`. DEFAULT 1 means an existing row reads as v1 with no backfill needed; NOT NULL means a missing value is a hard error rather than a silent v0. NEW FIELD ON RefCertificate `version: u32`. v1 is the pre-versioning 7-field payload (no `version` key in the signed JSON, so a v1 cert is byte-for-byte identical to today's cert). v2+ certs will include a `version` key and any new fields, both backwards-compatible: an old client reading a v2 cert sees the unknown `version` field and either ignores it (graceful) or refuses to verify (explicit). API CHANGES - list_certs and get_cert now include `version` in the JSON response. - issue_ref_certificate sets `version: 1` on every new cert. GL CHANGES - gl cert show reads the `version` field; missing field defaults to 1 (forward-compat with old servers). v1 certs go through the unchanged verify path. v2+ certs are explicitly rejected with an "upgrade the client" message rather than silently guessing the payload shape — a future client that supports v2 cannot accidentally treat a v1 cert as v2. GOLDEN-FORMAT FIXTURE v1_payload_matches_frozen_canonical_form pins the v1 signing payload byte-for-byte. Reverting this to a v2 shape (adding a `version` key) is what the versioned format forbids: an old client reading a v1 cert must not see a `version` key in the signed JSON. The same byte-form is what gl's verify_signature reconstructs in crates/gl/src/cert.rs, so any drift between node and CLI breaks the test instead of silently rendering every real cert INVALID. TESTS - 3 v1_payload_tests in crates/gitlawb-node/src/cert.rs: frozen-canonical-form, round-trip structural, default version is 1. - 2 new tests in crates/gl/src/cert.rs: missing_version_defaults_to_1_and_verifies, explicit_version_1_takes_v1_path. - 12 existing ref_certificate_tests still pass with the version column added. Compiles clean, 1091 tests pass with 0 regressions, gl 4 cert tests pass, clippy clean under -D warnings, fmt clean. Cross-PR overlap (declared in the PR description): - Twigpine#134 (anchors auth): independent. The cert API is unchanged in shape; auth gates apply as before. - Twigpine#285 (advisory-lock session affinity): independent. - Twigpine#306 (Content-Digest on signed requests): independent. - Twigpine#314 (small-order Ed25519): independent. v1 certs verify through the same path, which already enforces the small- order check from Twigpine#314 on the embedded node DID. - Twigpine#324 (libp2p keypair persistence): independent. - Twigpine#325 (gossip ref-update auth): independent. PR 1's signed HTTP push is the durable-intent producer; this PR owns the cert shape. The two PRs read and write the same cert table but do not step on each other (PR 1 calls issue_ref_certificate_idempotent; this PR keeps the deterministic cert id but does not change who calls what). - Twigpine#382 (replication withheld-subtree trees): independent. * fix(node,gl): address review feedback on cert version compat - Drop the duplicate `version` ALTER from the v1 migration bundle; v28 is now the sole owner of the column. - Add a v28 upgrade-path test (v25/v26 pattern) that seeds a legacy pre-v28 ref_certificates row, drops the column + migration record, re-runs migrations, and asserts DEFAULT 1 + legacy row reads as v1. - Extract a shared `v1_signing_payload` builder so the live signer and the frozen-vector test share one literal; a regression in the signer now fails the test. - Tighten gl's `version` parsing: missing key → v1, present value must be a JSON integer that fits in u32 and equals 1. Null, strings, floats, overflow, and unknown versions all return Err instead of collapsing to v1 (Reviewer 2). Add a truth-table test pinning every cell of the parser. - Extend the v1 forward-compat tests to actually round-trip through `verify_signature`, and add a regression test that pins the verdict branch rejects v2 even when the v1 signature would otherwise verify. * fix(cert): address CI failures on PR Twigpine#386 - cargo fmt --all (CI fmt check was red on the prior commit) - v28 upgrade-path test: switch version_column_default from fetch_one to fetch_optional, so a pre-v28 database with the column dropped returns Ok(None) rather than RowNotFound. The precondition assertion is what detects a missing column; RowNotFound would have masked a regression. - clippy `needless_borrow` on the v2 verdict-branch test: drop the leading `&` on `cert_json["signature"].as_str()`. * fix(gl,node): make the v2 rejection and issuer anchor real, and test them as such Round-2 findings, all three demonstrated by execution: - cmd_show's Ok(v != 1) verdict arm was dead code (parse_cert_version admits only 1), and the test aimed at it copied the match instead of calling the command. The match now mirrors the parser's contract and two end-to-end mockito tests drive cmd_show itself: a version-2 cert with a valid v1 signature fails --verify with the version named. - --verify no longer accepts the queried node's self-reported DID as a trust anchor: the node that served a forged cert can serve a matching self-report, and that fallback passed a wholly forged certificate with exit 0. --verify now requires --expect-node before claiming a trusted issuer, with a test proving the refusal (and the anchored positive control passing). - The node-side version test asserted version == 1 on its own literal; it now cross-checks the issuing construction: a version-1 claim must verify against the v1 payload builder's bytes rebuilt from the cert's own fields, and the v1 payload must carry no version key. * fix(node,gl): address round-2 reviewer findings on Twigpine#26 split 3/4 cert compat BREAKING CHANGE: gl cert show <id> --verify now requires --expect-node <did>; the node's self-reported DID is no longer trusted as a cert anchor. * fix(node): bind cert v2 test to live issuer via sqlx::test * fix(node,gl): address round-3 reviewer findings on Twigpine#26 split 3 cert compat - Stamp new certs v1 until v2 verifier ships; v2 issuance refused by shipped gl - Add v2_signing_payload with version in signed bytes, downgrade test - Verify signature in well-formed test, add DB read-back to issuer test - Fix README/db comments and version-refusal message * fix(gl): route cert list through error_for_status; correct cert show example Round 4 reviewer findings on Twigpine#26 split 3 cert compat: - P2 (cert.rs:113): cmd_list called .json() straight through on the cert list endpoint and let a gated 404 (whose body lacks a `certificates` key) fall into the empty-list branch, printing "No ref certificates" with exit 0. Wire cmd_list through the same error_for_status() gate that cmd_show and resolve_cert_id already use, and pin the new behavior with a load-bearing test (`cmd_list_surfaces_gated_404_as_err`) that drives cmd_list end to end against a 404 mock. cmd_show is unchanged. - P3 (README.md:314): the documented `gl cert show <id> --verify` example bound the certificate ID as the REPO positional, because the parser is `gl cert show [OPTIONS] <REPO> <ID>`. Insert the missing `<repo>` positional so the example matches the CLI parser. The original BREAKING CHANGE footer in bb553b6 carried the same shortened `gl cert show <id> --verify` example; this commit's footer supersedes it with the canonical command, which is what release-note scrapers read. The round-2 commit message itself is left in history unchanged; the new footer is the one callers should rely on. BREAKING CHANGE: gl cert show <repo> <id> --verify requires --expect-node <did>; the queried node's self-reported DID is no longer accepted as a cert anchor. * style(gl): fix fmt in cert list response parsing * fix(gl): label version refusals distinctly and clean cert show help A cert declaring an unsupported version printed INVALID, which reads as a failed Ed25519 check even though verify_signature never ran. The display now prints UNSUPPORTED VERSION for version refusals and keeps INVALID for real signature failures. The Show help no longer cites review rounds or commit history. * docs(node): align RefCertificate.version rustdoc with the signed-bytes v2 contract --------- Co-authored-by: Gravirei <gravirei@users.noreply.github.com> Co-authored-by: Kevin Codex <kevin@gitlawb.com>

…split 1/4) (Twigpine#558) * fix(node): durable post-receive outbox at the DB layer (Twigpine#26 split 1/4) Reviewer 2 closed PR Twigpine#224 on 2026-08-28 with a directive: split the work into four narrow PRs. This is Split PR 1 (durable post-receive lifecycle) at the DB layer; the handler refactor in crates/gitlawb-node/src/api/repos.rs:2007 (git_receive_pack) lands in the next slice so the test can drive the failure injection end-to-end. The pre-outbox crash window the reviewer flagged: receive_pack can apply a ref to disk and return Ok, and a process exit, a dropped future, or a DB failure before the bookkeeping at crates/gitlawb-node/src/api/repos.rs:2361 (push event + cert + webhook) loses the recovery record. Startup drain enumerates only sources written from that bookkeeping, so it cannot reconstruct the missing work. The partial fallback that re-derives from a row present in the bookkeeping substitutes did:key:recovered and an empty attestation, which is not equivalent to the original authenticated push. This commit adds the durable boundary the handler will lean on. NEW TABLE pending_ref_transitions (migration v27): - Written by the handler BEFORE smart_http::receive_pack, in state 'prepared', carrying the verified pusher DID, the raw RFC 9421 signature header, signature-input, and content-digest that authorized the push, the request id, and the parsed ref update. - The handler transitions the row to 'applied' on receive_pack Ok or 'cancelled' on Err. The drain reads only 'applied'. - A failed or cancelled receive-pack therefore leaves the row in 'prepared' or 'cancelled', which the drain never promotes. This is what closes the reviewer's second proof ("a failed or cancelled receive-pack does not turn a prepared intent into completed accounting or anchoring"). NEW TABLE anchor_jobs (migration v27, owned by PR 1, consumed by PR 2): - One row per (repo_id, ref_name, old_sha, new_sha) transition. PR 1 inserts it on 'applied'; PR 2 reads it and updates claimed_at. - ON CONFLICT (id) DO NOTHING makes the insert idempotent on the deterministic id, so a recovery re-pass cannot create a second upload request. This is the handoff boundary; the bundler call itself is PR 2. NEW DB METHODS on Db: - insert_pending_ref_transitions: writes one 'prepared' row per ref update, returns the persisted rows. - mark_pending_ref_transitions_applied / _cancelled: state flip, gated on the FROM state, idempotent. - list_pending_ref_transitions_applied: drain query, oldest first. - delete_pending_ref_transition: called by recovery after the artifacts land; a third pass is a no-op. - record_push_with_id: ON CONFLICT (id) DO NOTHING on the deterministic id. - insert_ref_certificate_idempotent: ON CONFLICT (repo_id, ref_name) DO NOTHING, returns None if a live-path cert already exists. - insert_anchor_job_idempotent: ON CONFLICT (id) DO NOTHING on the deterministic per-transition id. NEW HELPERS in db/mod.rs: - deterministic_id: SHA-256 hex with an ASCII Unit Separator between fields so two distinct tuples never collide on prefix overlap. - push_event_id_for, ref_cert_id_for, anchor_job_id_for: the derived ids above, one helper per artifact so a caller cannot derive a wrong id by mistake. NEW STRUCTS: - PendingRefTransition: the row shape. - AnchorJob: the handoff row shape. - pending_state: const strings ('prepared' / 'applied' / 'cancelled') shared by tests, the producer, and the drain so a typo on one side cannot silently mismatch the other. NEW TESTS in db::pending_ref_transition_tests (8 tests, all green): - insert_then_mark_applied_flips_state_for_every_ref: producer contract. - mark_applied_is_idempotent_on_repeat: re-fire is a no-op. - cancelled_rows_are_not_returned_by_the_drain: reviewer's second proof at the DB layer. - prepared_rows_are_not_returned_by_the_drain: same proof for the pre-flip state (handler crashed before reaching post-Ok). - mark_cancelled_is_idempotent_on_repeat: counterpart. - drain_then_re_derive_is_idempotent: reviewer's first proof at the DB layer. Inserts a row in 'applied' state directly via insert_pending_ref_transition_for_test, drains it, derives the artifact ids twice, exercises record_push_with_id and insert_anchor_job_idempotent directly, asserts exactly one push event row and exactly one anchor job row regardless of how many times the drain runs. - deterministic_id_avoids_prefix_overlap_collisions: the separator regression test. - push_event_id_for_is_stable: derived ids match across calls and differ on each varied input. OTHER: - Make RefUpdate and its fields pub(crate) so the DB methods can iterate the parsed ref updates. No public API change. NOT IN THIS SLICE (the handler refactor, next commit): - The receive-pack handler does not yet call insert_pending_ref_ transitions before the receive_pack call, nor mark_applied / mark_cancelled after. The DB layer is in place for it; the handler will call these methods and the startup drain will be wired in main.rs. - The startup drain in main.rs is not yet called; it will iterate list_pending_ref_transitions_applied, re-derive the artifacts, and delete the row. - The cert/push event issuance in cert.rs and the bookkeeping in api/repos.rs:2361 are not yet changed to use the deterministic ids. The helper functions exist and are tested; the callers follow. Compiles clean, clippy clean under -D warnings, fmt clean. * fix(node): wire durable outbox into the receive-pack handler (Twigpine#26 split 1/4) This is the handler-level half of Split PR 1. The previous commit added the migration and the DB methods; this one threads them through crates/gitlawb-node/src/api/repos.rs:2007 (git_receive_pack), the cert issuer, and the startup drain. CHANGES IN THE HANDLER ====================== In git_receive_pack, AT THE LAST POSSIBLE MOMENT before the smart_http::receive_pack call, the handler now: 1. Generates a per-handler request_id (UUID). 2. Captures the raw Signature, Signature-Input, and Content-Digest headers from the request. 3. Calls db.insert_pending_ref_transitions(request_id, ...) which writes one row per ref update in state 'prepared'. The receive_pack call runs as before. After it returns: 4. On Ok: db.mark_pending_ref_transitions_applied(request_id) — the row is the ONLY thing that promotes a 'prepared' row to 'applied', and the drain reads only 'applied' rows. A process crash before this call leaves the row in 'prepared', which the drain never promotes. 5. On Err: db.mark_pending_ref_transitions_cancelled(request_id) — a failed receive_pack leaves the row in 'cancelled', which the drain never promotes. This is what closes the reviewer's two proofs: Proof 1 (crash window): if the process dies after mark_pending_ref_transitions_applied but before the bookkeeping writes, the row is in 'applied' and the next startup drain re-derives the push event, the per-ref certificate (carrying the ORIGINAL pusher DID, not a placeholder), and the anchor handoff. The drain uses the persisted authentic pusher DID and signature header, not a recovered placeholder. Proof 2 (failed receive-pack): the row is only ever flipped to 'applied' in the explicit Ok branch above. A 'prepared' or 'cancelled' row is invisible to the drain, so a failed or dropped receive_pack cannot turn a prepared intent into completed accounting or anchoring. BOOKKEEPING IS NOW DETERMINISTIC-ID =================================== The post-Ok bookkeeping at api/repos.rs:2448 now uses: - record_push_with_id with push_event_id_for(request_id, first_ref) — ON CONFLICT (id) DO NOTHING, so a recovery re-pass is a no-op. - issue_ref_certificate_idempotent with ref_cert_id_for(request_id, ref_name) — ON CONFLICT (repo_id, ref_name) DO NOTHING, returns None if a live-path cert already exists. - insert_anchor_job_idempotent with anchor_job_id_for(repo_id, ref_name, old_sha, new_sha) — the per-transition tuple key, so two pushes to the same ref produce one anchor upload per landed state. The legacy entry points (record_push, issue_ref_certificate, insert_ref_certificate) remain for callers that prefer a fresh UUID per cert; they are #[allow(dead_code)] for the PR 3 cert/CLI compat pass to decide whether to keep or remove. STARTUP DRAIN ============= crates/gitlawb-node/src/main.rs calls durable_outbox::drain_pending_ref_transitions(state, 1000) ONCE before serving, after migrations and after the existing peer / quarantine prunes. Non-fatal: a transient drain failure logs and leaves the rows for the next startup. durable_outbox::drain_pending_ref_transitions reads every 'applied' row, calls derive_one (which re-derives the three artifacts using the persisted authentic pusher DID and signature header), then deletes the row. A second drain pass is a no-op for both the artifacts (idempotent inserts) and the row (gone after the first pass). NEW END-TO-END TESTS ==================== crates/gitlawb-node/src/durable_outbox.rs adds three end-to-end tests in drain_tests, complementing the eight DB-layer tests in db::pending_ref_transition_tests: - drain_re_derives_all_three_artifacts_for_an_applied_row: the reviewer's first proof. Inserts a row in 'applied' state (the crash window), drains, asserts exactly one push event row, exactly one cert row carrying the original pusher DID (not a placeholder), and exactly one anchor job row. Asserts the deterministic cert id matches. Asserts a second drain pass is a no-op. - cancelled_row_produces_no_artifacts: the reviewer's second proof for the cancelled state. A row in 'cancelled' (receive_pack returned Err) is invisible to the drain. - prepared_row_produces_no_artifacts: the reviewer's second proof for the prepared state. A row in 'prepared' (handler crashed between insert_prepared and the post-Ok branch) is invisible to the drain. Each test names the invariant it pins and the production line it covers. Reverting that line turns the named assertion red. Compiles clean, 1099 tests pass with 0 regressions, clippy clean under -D warnings, fmt clean. Cross-PR overlap (declared in the PR description): - Twigpine#134 (anchors auth): composes. The /arweave/anchors route already requires auth; this PR does not change the route. - Twigpine#285 (advisory-lock session affinity): composes. The durable intent is written inside the same handler that holds the lock from Twigpine#285; no changes to the lock layer. - Twigpine#306 (Content-Digest on signed requests): composes. PR 1 persists the Content-Digest header that Twigpine#306 makes mandatory. - Twigpine#314 (small-order Ed25519): independent. PR 1's tests use strong keys. - Twigpine#324 (libp2p keypair persistence): independent. PR 1 does not touch p2p identity. - Twigpine#325 (gossip ref-update auth): independent. PR 1's signed envelope is the HTTP-side equivalent, not the gossip-side. - Twigpine#382 (replication withheld-subtree trees): independent. PR 1 does not touch replication or pin selection. * fix(node): address four reviewer findings on Twigpine#26 split 1/4 - P1-A: add startup reconcile step that promotes `prepared` rows to `applied` when the on-disk ref matches the row's `new_sha`. The recovery drain (which only reads `applied` rows) can now pick up a ref that landed when the live handler's `mark_pending_ref_transitions_applied` call errored or was interrupted. Strict SHA equality is the load-bearing check — a `prepared` row whose target did NOT actually land stays `prepared`. - P1-B: route the live handler's cert issuance through `cert::issue_ref_certificate` (the upsert) instead of `issue_ref_certificate_idempotent` (DO NOTHING). A re-push to the same ref now updates the cert's `old_sha` / `new_sha` / `pusher_did` / `issued_at` / `signature` to the new transition while preserving the deterministic `cert_id`. The recovery drain keeps the idempotent variant; both paths collapse to one row. - P2-A: refactor the drain into a `drain_pending_ref_transitions_with` testable seam that does per-row log-and-continue, and add `drain_pending_ref_transitions_all` that loops `DRAIN_PER_PASS_LIMIT=1000` rows for `DRAIN_MAX_PASSES=10` passes. A failing row no longer stalls the batch; a backlog above 1000 rows is fully processed across passes. - P2-B: add a `first_ref_name` column to `pending_ref_transitions` via migration v28. The live handler hoists a `first_ref_name` local and persists it on every row of the same `request_id`. The drain's `derive_one` keys the push event id on `row.first_ref_name` instead of `row.ref_name`, so live and recovery produce the same id and `ON CONFLICT (id) DO NOTHING` collapses a multi-ref push to one push event row (and one trust- score bump). Cert and anchor ids stay per-ref / per-transition. * fix(node): address four reviewer findings on Twigpine#26 split 1/4 (round 2) * fix(node): address reviewer round-3 findings on Twigpine#26 split 1/4 - P1: Delete outbox rows after live durable effects complete so they don't replay on every restart - P1: Parse git report-status for per-ref ok/ng results; mark only proven rejections as cancelled, uncertain outcomes as recoverable - P1: Introduce 'uncertain' state for receive-pack errors where some refs may have landed; reconcile checks these against disk at startup - P2: Promote deletion transitions during reconcile (new_sha == ZERO_SHA with absent ref = successful deletion) - P2: Loop reconcile across multiple passes so backlogs beyond the first page are processed in the same startup Closes review round 3 findings from reviewer-1 and reviewer-2. * fix(node): fix CI failures from round-3 changes - Add COMMENT ON TABLE to v29 migration so migration_bodies_are_non_empty passes - Return error on non-zero receive-pack exit (preserving backward compat with tests that expect Err(AppError::Git(_))) while still parsing report-status for outbox row handling * fix(node): update inv22 gate tests for receive_pack_raw refactor - F3 gate: scan for smart_http::receive_pack_raw( instead of receive_pack( - U5 gate: scan for all_refs_ok instead of receive_result.is_ok() * fix(node): require reflog proof before the reconcile promotes a row (Twigpine#26 split 1/4) Closes the second half of the reviewer's round-3 [P1]: the startup reconcile still promoted on `disk_refs.get(ref) == row.new_sha`, which also matches a coincidental current tip (old=B, new=A while the ref is already A). That is not an exotic case — it is the ordinary shape of a REJECTED push, since git refuses an update whose expected old value does not match the ref. Both the SHA check and the MAX_RECONCILE_AGE window pass, the push never happened, and the drain then writes a push event, a signed certificate and an anchor for it. The live path proves landings from git's report-status body; that body is gone by the time the reconcile runs, so the proof is re-derived from the repository. `git::store::ref_reflog_entries` reads `logs/<ref>` and a row is promoted only when an entry carries its exact `old -> new` pair, stamped at or after the row was written (REFLOG_CLOCK_SKEW absorbs git's whole-second truncation against the row's sub-second `created_at`). The timestamp floor is what separates a landing from a later push that re-introduced the same pair: proof must postdate the intent it proves. Deletions stay exempt from the reflog half and keep the absence-plus-age rule already in place — git removes a ref's reflog along with the ref, so no other evidence can exist for one. `init_bare` now sets `core.logAllRefUpdates`, which bare repos default off; a repo with no reflog yields no proof and its rows stay put for human-attended recovery rather than becoming accounting the node cannot substantiate. Tests: reconcile_refuses_a_coincidental_tip_with_no_reflog_proof, reconcile_promotes_a_row_the_reflog_proves, reconcile_leaves_a_row_prepared_when_the_repo_keeps_no_reflog, reconcile_refuses_a_reflog_entry_older_than_the_row, reconcile_still_promotes_a_landed_deletion_which_can_have_no_reflog, init_bare_keeps_reflogs_so_a_landing_can_be_proven, ref_reflog_entries_is_none_when_the_repo_kept_no_log. No migrations added or renumbered. * fix(node): walk the reconcile backlog on a keyset cursor (Twigpine#26 split 1/4) The multi-pass reconcile looped but never advanced. Each pass re-issued the same cursor-less `LIMIT n` query, and unlike the drain — which deletes every row it finishes, so its next page is always new work — the reconcile leaves every row it cannot promote exactly where it was. One unprovable row at the head of the ordering therefore pinned page one on every pass, and the backlog behind it was never examined at all, which is the condition the multi-pass loop was added to remove. Rows keep ageing toward MAX_RECONCILE_AGE while they wait, so "picked up next restart" can mean "never recovered". Pages now resume strictly after the `(created_at, id)` of the last row EXAMINED, via `list_pending_ref_transitions_prepared_or_uncertain_after`. A keyset cursor rather than an OFFSET because rows leave the set underneath the walk when they are promoted: an absent row simply does not appear on a later page, and it can never shift an unvisited row into a page that was already read. Pass budget, per-pass limit, short-page exit and the residual-backlog warning are unchanged. This matters more with the reflog gate in place: a landing in a repo that keeps no reflog is PERMANENTLY unprovable, so before this it would jam page one on every startup rather than once. Tests: reconcile_all_walks_the_backlog_past_the_first_page, reconcile_all_advances_past_an_unprovable_row (whose blocker is a no-reflog row, the class the gate introduces). * fix(node): bound the reflog read to a recent tail (Twigpine#26 split 1/4) `ref_reflog_entries` slurped the whole reflog. A reflog grows one line (~150 bytes) per ref update and how often a ref is updated is PUSHER-controlled, so that was an attacker-sized allocation, taken once per stranded row, at startup — the moment the node can least absorb it. Every other attacker-influenced read in this crate is bounded (read_body_capped, MAX_SIGNATURE_ENTRIES, the pin/walk budgets); this one should be too. The bound costs nothing in proving power, which is why it is a ceiling rather than a tradeoff: the landing gate only ever accepts an entry stamped at or after `created_at - REFLOG_CLOCK_SKEW`, and reflogs are append-ordered oldest-first, so every entry that could possibly qualify is at the tail. The read now seeks to the last REFLOG_TAIL_BYTES (256KB, ~2000 recent updates to one ref) and `take`s that many bytes, so the allocation stays bounded even if the file grows between the stat and the read. A window into the middle of a file starts mid-record, so the bytes before its first newline are discarded: without that, a boundary landing inside a record's old SHA leaves a suffix that still tokenizes and yields a truncated SHA as a bogus `old -> new` pair — and landing proof is an exact pair match, so a bogus pair is a fabricated proof. An entry older than the window reads as absent, which is the safe direction: the caller treats "no matching entry" as unproven and leaves the row where it is. `Ok(None)` for a missing file, and the absence-of-evidence contract, are unchanged. Tests: ref_reflog_entries_reads_whole_records_from_the_recent_tail (lays the file out so the boundary lands 20 bytes into a record's old SHA — the alignment that would otherwise parse), an_entry_older_than_the_reflog_tail_reads_as_unproven. * fix(node): read the report through both side-band frames The report-status is framed twice whenever the client negotiates side-band-64k, which `git push` over smart HTTP does: the outer side-band envelope carries a stream that is itself pkt-line encoded. One strip pass left the first line as `000eunpack ok`, so the unpack check failed and parse_report_status returned None — read by the caller as "no report", which keeps every declared ref. The per-ref landing gate was therefore inert for exactly the pushes it exists to filter. The regression test is a byte-for-byte capture from git 2.50.1 rejecting one ref of a two-ref push, because a hand-written single-framed fixture parses under the old code and hides the case. * fix(node): address round-4 reviewer findings on Twigpine#26 split 1/4 * fix(node): rustfmt round-4 reviewer fixes * fix(node): remove empty line after doc comment * fix(node): drop redundant reflog gate; implicit-ok on exit-zero no-report * fix(node): address round-5 reviewer findings on Twigpine#26 split 1/4 * fix(db): v30 migration — add receive_pack_requests table and ordinal column The reviewer's round-5 finding: the push event identity was encoded into a mutable per-ref column (first_ref_name) whose correct value is knowable only after git, and the correction was not committed atomically with the per-ref outcomes. A crash between git updating a later ref and the rewrite left the durable rows naming the rejected ref, and derive_one's row.ref_name == row.first_ref_name guard then meant no push event ever landed for the accepted child. Per the state-transition model at .gravirei/plans/state-model-durable-post-receive.md, this migration introduces the request-level record that owns the push event and the trust score, and extends the per-ref child with an ordinal column the drain and the effect executor walk together. first_ref_name is dropped; the push event id is keyed on (request_id, accepted_ordinal) and lives on the request row. The next commit (handler rewrite) wires the live path and the recovery drain against the new tables. BREAKING CHANGE: pending_ref_transitions.first_ref_name is dropped. Callers that read or write that column must move to receive_pack_requests.accepted_ordinal. * fix(node): rewrite receive-pack handler against the request-level model (Twigpine#26 split 1/4 step 2) The v30 migration added receive_pack_requests and dropped first_ref_name, but no Rust code used either. The handler still ran a four-branch per-ref state flip plus a first_ref_name rewrite after git returned, which is the mixed-outcome bug a push with the first ref rejected exposes: the live path and the drain computed different push-event ids. - Insert a receive_pack_requests row in state `received` BEFORE git runs (insert_receive_pack_request), carrying the request bytes and the SHA-256 of the body. Crash between intent and git return is now recoverable via the reconcile step. - Drop the first_ref_name rewrite at api/repos.rs:2454. The push event identity is now (request_id, accepted_ordinal); accepted_ordinal is computed once at the per-ref state flip. - Re-key push_event_id_for and ref_cert_id_for on (request_id, ordinal). Anchor job id stays per-transition. - Transition the request row to outcomes_committed (with parsed_report and accepted_ordinal) or rejected_at_git (no report + non-zero exit) in the same handler tail as the per-ref state flip. The drain (step 3) picks up outcomes_committed rows; today the live path also runs the per-ref effects inline. - Stub the step-3 surface (mark_request_effects_pending, complete, list_receive_pack_requests_due, update_request_attempt) with #[allow(dead_code)] + contract-pin comments so the rewrite is bisectable: reverting this commit restores the pre-rewrite live path. The U5 gate (replication tail spawn inside push_succeeded, before guard.release) is preserved; inv22_replication_tail_spawns_at_the_ durability_boundary stays green. * fix(node): use raw bytes for request_bytes_hash (Twigpine#26 split 1/4 step 2) The v30 migration defined request_bytes_hash as BYTEA but the handler was binding a hex-encoded String. Postgres rejected the insert with "column request_bytes_hash is of type bytea but expression is of type text" and the handler shed the push with a 503. Switch the handler to bind the raw 32-byte digest and update the ReceivePackRequest struct field type to Vec<u8> to match. The drain-side test fixture already used Vec<u8> and needs no change. Pinned by the bin test suite going from 24 failures (all the receive-pack-cap tests that send a 4-byte body) to 0 regressions on the new model. * fix(node): factor out apply_request_effects; drain walks receive_pack_requests (Twigpine#26 split 1/4 step 3) The step-2 commit moved the request row to be the unit of work but left the per-ref effects fan-out inline in the handler and the drain walking pending_ref_transitions per-ref. Step 3 factors the effects fan-out into apply_request_effects(state, request_id) and rewrites the drain to walk receive_pack_requests. - apply_request_effects lives in durable_outbox.rs; the live handler in api/repos.rs and the drain both call it. Idempotent on (request_id, accepted_ordinal). Returns EffectsOutcome::{Done, Nothing, Retry}. - Drain switches from list_pending_ref_transitions_applied + derive_one to list_receive_pack_requests_due + apply_request_effects. derive_one and the per-ref drain entry points are deleted. - The step-3 stubs in db/mod.rs (mark_request_effects_pending, mark_request_complete, list_receive_pack_requests_due) lose their #[allow(dead_code)] annotations; every stub has a caller in this PR. - Reconcile (reconcile_prepared_from_disk_all) is unchanged. The crash window between intent durable and outcomes commit still routes through per-ref reflog proof. - Drain tests rewritten to stage receive_pack_requests rows; the per-ref fixtures (make_row, lookup_accepted_ordinal) are gone. - New inv26_step3_live_and_drain_share_apply_request_effects assertion pins the live/drain sharing and the per-request drain walk. * fix(node): bounded retirement purge for terminal request rows (Twigpine#26 split 1/4 step 4) The v30 partial index idx_receive_pack_requests_completed_at exists but no code reads it. Step 4 wires a periodic purge task that deletes terminal `complete` and `rejected_at_git` rows older than the retention window, along with their per-ref children. `quarantined` (a step-5 state) is never purged by the timer. - `purge_completed_receive_pack_requests(older_than, limit)` — deletes parent requests using the v30 partial index. - `purge_completed_pending_ref_transitions(older_than, limit)` — deletes children of purged parents, gated on the child's own applied_at / cancelled_at. - `purge_request_queue(db, retention_days, limit)` — orchestrator in durable_outbox.rs that calls both and returns the totals. The deletion order (parents first, then children) is the contract; a crash mid-purge leaves orphaned children that the next pass will pick up. - `spawn_queue_lifecycle_sweep` in main.rs — periodic task on the same detached pattern as `spawn_legacy_cid_sweep`, 24-hour interval, shutdown-aware. The interval matches the spec's "one per cluster per day" target. - Config knobs `queue_retention_days` (default 7, range 1..=365) and `queue_purge_batch` (default 1000, matches DRAIN_PER_PASS_LIMIT). - 3 new `durable_outbox::drain_tests::purge_*` tests pin the contract: only old terminal rows are deleted, the second pass is a no-op, and a row inside the retention window survives. - New `inv26_step4_queue_lifecycle_purge_is_wired` gate asserts the wiring (main.rs calls the purge, the DB helpers exist, the Config knobs exist). * fix(node): reference-transaction marker + quarantined state + failure matrix (Twigpine#26 split 1/4 step 5) Steps 2-4 gave the request row the unit of work, the shared executor, and the bounded retirement policy. Step 5 closes the evidence gap: the reconcile now requires a per-request marker ref (refs/gitlawb/requests/<id>) whose value matches request_bytes_hash. A missing or mismatched marker quarantines the request; an operator reclassifies it. - v31 migration: adds `quarantined` to the state vocabulary and a partial index for operator queries. - Handler writes the marker ref before git-receive-pack; the marker is causally bound by being in the same async task as the receive-pack call. The marker's value is content-addressed (git hash-object of the request bytes), so the gate compares consistent SHAs on both sides. - git::store::read_ref reads a single ref's value, returning Ok(None) for absent refs. Used by the marker gate. - git::store::marker_value_for computes the content-addressed marker value; both the live handler and the reconcile use it so the write and the read agree. - Reconcile gains a marker gate between the age check and the reflog proof. Mismatch or absent ⇒ mark_request_quarantined + mark_children_rejected_for_quarantined_parent. - effects_max_attempts bound (config knob, default 8) flips retry-stuck requests to `quarantined` after N attempts, closing the infinite-retry DoS window. - New failure_matrix_tests submodule covers the spec's outcome × ref-kind × exit-point × recovery-scenario matrix (6 cells). - New inv26_step5_marker_quarantine_and_bound_are_wired gate asserts the marker gate, the bound check, the handler's pre-receive-pack ordering, and every load-bearing helper. - Existing 7 reconcile tests updated to stage a marker ref via the new `stage_marker` test helper. * fix(node): converge durable post-receive to singular request-level lifecycle Unify producer, evidence, aggregate outcome, executor, retry, and retirement on the request row: atomic intent and outcome commits, synthetic normalized reports for implicit-ok/reconciled paths, reconcile parent promotion with fail-closed deletions and competing-claimant guard, retry progression from both executable states with backoff/quarantine, terminal-parent-gated purge with marker cleanup and hidden refs, minimal digest-only intent plus request-level RFC9421 proof (v32). * fix(node): harden request occurrence lifecycle, proof, retry, and retirement Reject incomplete report framing and omitted refs as indeterminate, preserve uncertain children on completion, terminalize all-rejected, bind reconcile with landing history, durable proof with ack gate, occurrence-keyed anchors, background due loop, deletion quarantine with operator resolve, children-before-parent purge with marker tombstones, recovery prereq upgrade check, and bounded marker runner. * fix(node): keep recovery prereq upgrade best-effort on push path Refusing pushes when git config upgrade fails broke fake-git and non-repo disk-path tests with 503. Reconcile already fails closed on missing reflogs, so downgrade to warn-and-proceed. * fix(node): close reviewer round on outcome authority and lifecycle ownership Gate effects on unpack_ok with cleared ordinal and terminal no-effects, intersect executor with applied children, treat absent report-status as indeterminate regardless of exit, require landing history before child delete, claim due requests with recoverable leases, dedupe webhooks by occurrence ledger, ack-gate proof retention with terminal disposition, fair marker tombstones with dead-letter, kill_on_drop marker bounds, and loud migration version collision guard. * fix(node): load-bearing coverage for intent, guards, and delivery ledger Handler intent test plus inv22 gate so disabling the durable insert turns red; unpack-false, mixed ok/ng, divergent cancelled, partial sibling, and proof-ack tests pin each executor guard; webhook deliveries record sent_at with stale-pending reclaim; stale parsed_report comment corrected. * fix(node): centralize live retry, bound outcome commit, close retention orphans Route live Retry/Err through schedule_request_retry_or_quarantine so attempt progression matches the drain; retry post-git outcome commits 3x before restart repair; block terminal purge while non-terminal children exist; add v27 upgrade-path test. * fix(node): document attended-restart commit policy and pin executor retry arms Track outcome-commit success, skip metrics/touch on failure, correct the lease-expiry comment to startup reconcile; add restart-repair test for stuck received parents plus RED tests for landing-history and proof-ack failure paths. * fix(node): correct marker prereq comment to warn-and-proceed * fix(node): single partial-completion model with disposition gate Split apply_request_effects into phase-1 bundle (push, cert, anchor, history, webhook, proof ack before child deletion) and phase-2 gate that retries while non-cancelled siblings remain; Nothing only when nothing owed. Gate tail, Tigris, and effects on PostGitDisposition with documented replication carve-out; add partial-sibling webhook and disposition tests; fix stale comments. * fix(node): close review round on outbox ordering, marker visibility, and repair reachability Address the P1/P2 review findings: await the webhook delivery claim before accepted-child deletion; exempt the marker namespace from the fail-closed ref peeling guard so visibility walks tolerate blob-pointing request markers; keep request marker deletion bounded in the purge path; promote cross-page siblings via idempotent report superset; run stuck-parent repair when the prepared queue is empty; bound the durable intent write while admission permits are held; remove dead proof verification scaffolding. * fix(node): close review round on pre-git refusal lifecycle, namespace gate, and promotion merge * fix(node): close review round on namespace gate, intent lifecycle, and promotion atomicity Namespace gate hardening: - Refuse non-UTF-8 ref-update lines (git accepts bytes ≥0x80; gate never sees them) - Catch bare 'refs/gitlawb' name (starts_with missed it) - Add deny test for both holes plus refusal wiring verification Intent lifecycle guards: - Add IntentDropGuard: terminalize stranded intents on dropped futures - Bound refuse_receive_pack_before_git to 10s (no statement_timeout on pool) - Guard mirror fetch: hideRefs blocks non-exempt refs/gitlawb/* from +refs/*:refs/* Promotion merge atomicity: - Take row under SELECT FOR UPDATE so merge is atomic with state read - Prevents racing due worker from stranding newly applied children outside report * fix(test): correct inv22 namespace gate assertions to match actual implementation The test was looking for the wrong patterns: - UTF-8 check: error message string, not pre-loop condition - Namespace check: `*r == "refs/gitlawb"`, not `ref_name ==` - Visibility exemption: `&&` logic (both false to exclude), not `||` * chore: cargo fmt * fix(node): phase-aware intent guard, mirror import prune, terminal-state merge * fix(node): guard cleanup retry with fates, fail-closed mirror prune, refusal coverage * fix(node): bound guard attempts, sibling-wait outcome, fail-closed prune enumeration * fix(node): sibling-wait outcome, no-report path, bounded prune and guard retry * fix(node): no-report durability, cert landing order, bounded reconcile git, flush checks * fix(node): gate trust-score bump on a new push event row * chore: update rustls 0.23.37 → 0.23.45 to resolve RUSTSEC-2026-0285 * fix(node): surface git's report-status when a stdin EPIPE follows child exit * fix(node): cap receive-pack ref-update count before per-ref work and intent * fix(node): cap ref-update parsing in-loop and dedupe identical commands * docs(node): correct round-4 comment claims on client outcome and gate cost * fix(node): single replication tail, proven marker taxonomy, claimed webhook delivery (Twigpine#558) - One post_receive_replication_tail per push: the carve-out spawn and the durability-bound spawn are mutually exclusive positions on the same proven-landed ref set; inv22 now fails on any unfiltered or ungated spawn. - Marker reconcile: bounded-read errors (git Err/deadline) stay prepared and retry instead of quarantining as 'missing marker ref'; only a successfully read marker proves missing or mismatch. Err-injection test pins no-quarantine on unproven reads. - Claimed webhook delivery: the synchronous claim phase returns the claimed Webhook rows so the send task never re-lists; a list failure after claim can no longer drop claimed deliveries. Source gate pins it. * docs(node): name claimed-hooks variant in fire_event_occurrence doc * fix(node): order pending_ref_transitions create before outbox alters, fill v29 (Twigpine#558) * fix(node): proven-missing marker taxonomy, v38 upgrade test, report-ok tail fixtures (Twigpine#558) * fix(node): read marker refs via rev-parse so present refs return their oid (Twigpine#558) --------- Co-authored-by: Gravirei <gravirei@users.noreply.github.com> Co-authored-by: Kevin Codex <kevin@gitlawb.com>

beardthelion mentioned this pull request Aug 8, 2026

feat(node): add a commit status reporting surface #304

Open

11 tasks done

coderabbitai Bot reviewed Aug 8, 2026

View reviewed changes

Comment thread crates/gitlawb-core/src/http_sig.rs Resolved

beardthelion requested a review from jatmn August 8, 2026 12:42

beardthelion added crate:core gitlawb-core — identity, certs, encrypt, DID/UCAN crate:node gitlawb-node — the serving node and REST API kind:bug Defect fix — wrong or unsafe behavior subsystem:identity DID/UCAN, http-sig auth, push authorization labels Aug 8, 2026

jatmn requested changes Aug 9, 2026

View reviewed changes

This was referenced Aug 15, 2026

Signed writes break on a same-origin 301/302/303: the redirect rewrites POST to a bodyless GET but keeps the signature headers #336

Open

HttpSignature::parse panics on a Signature-Input where ')' precedes '(', reachable pre-auth by any caller #348

Open

This was referenced Aug 15, 2026

fix(node): make a verified signature single-use on mutation routes (#253 phase 1) #261

Open

docs: implement language-agnostic PROTOCOL.md wire spec #372

Closed

beardthelion mentioned this pull request Aug 25, 2026

fix(node): harden Arweave anchoring and add verification (#26) #224

Closed

3 tasks done

beardthelion requested a review from jatmn August 28, 2026 04:39

jatmn approved these changes Aug 28, 2026

View reviewed changes

Gravirei mentioned this pull request Aug 28, 2026

docs: state that GITLAWB_ENFORCE_OWNER_PUSH defaults to true #383

Closed

This was referenced Aug 28, 2026

fix(node): durable post-receive outbox for receive-pack (#26 split 1/4) #384

Closed

fix(node): ANS-104 codec and recovery policy types (#26 split 2/4) #385

Closed

fix(node): version ref_certificates for forward compat (#26 split 3/4) #386

Closed

beardthelion mentioned this pull request Sep 15, 2026

fix(core): compute created-skew in checked arithmetic (#358) #457

Closed

12 of 17 tasks

euxarist reviewed Sep 27, 2026

View reviewed changes

chore: re-trigger code quality check

ef181bf

beardthelion added this pull request to the merge queue Nov 4, 2026

Merged via the queue into main with commit 189aad9 Nov 4, 2026
19 checks passed

jatmn assigned beardthelion Nov 4, 2026

github-actions Bot mentioned this pull request Sep 27, 2026

chore(main): release 0.8.0 #307

Open

beardthelion deleted the fix/require-content-digest-on-signed-requests branch November 4, 2026 22:58

coderabbitai Bot mentioned this pull request Nov 5, 2026

fix(node): bound the request body the signature middleware buffers before it verifies #262

Merged

beardthelion mentioned this pull request Nov 5, 2026

fix(node): ANS-104 codec and recovery policy types (#26 split 2/4) #524

Merged

10 of 17 tasks

Navigation Menu

Repository navigation

fix(node): require Content-Digest on a signed request - #306

fix(node): require Content-Digest on a signed request#306
beardthelion merged 3 commits into
mainfrom
fix/require-content-digest-on-signed-requests

beardthelion commented Aug 8, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Aug 8, 2026 •

edited

Loading

Sequence Diagram(s)

Uh oh!

coderabbitai Bot left a comment

Uh oh!

Uh oh!

jatmn left a comment

Uh oh!

beardthelion commented Aug 15, 2026

Uh oh!

beardthelion commented Aug 28, 2026

Uh oh!

jatmn left a comment

Uh oh!

beardthelion commented Sep 7, 2026

Uh oh!

euxarist left a comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

beardthelion commented Aug 8, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation & context

Kind of change

What changed

How a reviewer can verify

Before you request review

Protocol & signing impact

Notes for reviewers

Summary by CodeRabbit

Uh oh!

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

Uh oh!

Sequence Diagram(s)

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jatmn left a comment

Choose a reason for hiding this comment

Findings

Uh oh!

beardthelion commented Aug 15, 2026

Uh oh!

beardthelion commented Aug 28, 2026

Uh oh!

jatmn left a comment

Choose a reason for hiding this comment

Uh oh!

beardthelion commented Sep 7, 2026

Uh oh!

euxarist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

beardthelion commented Aug 8, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 8, 2026 •

edited

Loading