Repository navigation
docs(id): 2026-10-28 program investigations — TigerBeetle + Cloudflare Workers fit - #2067
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 40 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8bbefcab68
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - **UDP: there is no UDP socket API.** Iroh's transport is QUIC, and QUIC runs | ||
| over UDP; hole punching and Iroh relay (DERP-style) flows are likewise | ||
| UDP/QUIC-shaped. None of that can execute inside a Worker or Durable Object. |
There was a problem hiding this comment.
Evaluate relay-only Iroh before ruling out protocol compatibility
The lack of UDP rules out direct connections and hole punching, but not Iroh's relay transport. Iroh's official Wasm documentation describes browser peers that cannot send UDP and nevertheless communicate through relays, including an echo-server example. The repository also documents the WebSocket relay protocol in doc/2026-10-11T11-08-42Z_design_remaining_work/research-round2/cloudflare-workers/RESULTS.md. Workers compatibility and connection-lifetime costs still need investigation, but the UDP-only premise does not establish that an application-level HTTPS bridge is mandatory. Qualify the conclusion and assess the relay-only Wasm path separately.
Useful? React with 👍 / 👎.
| model issuance; a `credits_must_not_exceed_debits`-style constraint would | ||
| cap it. TigerBeetle does not pick for you. |
There was a problem hiding this comment.
Correct the constraint recommended for limiting issuance
For the issuer → recipient minting model defined here, issuance increases the issuer's debits. credits_must_not_exceed_debits therefore does not cap issuance; it constrains incoming credits instead, so arbitrarily large mint transfers would still pass that constraint. The Account reference specifies this direction explicitly. Describe a prefunded issuance account with debits_must_not_exceed_credits, or a separate supply-limit construction, rather than recommending the opposite flag as a supply cap.
Useful? React with 👍 / 👎.
| - **Account closure exists but is narrow.** An account can be closed (via | ||
| `flags.closing_debit`/`closing_credit` pending transfers) once its net | ||
| balance is zeroed; a closed account "will reject further transfers, except |
There was a problem hiding this comment.
Separate account freezing from zero-balance closing entries
The zero-balance prerequisite incorrectly excludes a database-enforced freeze for funded accounts. The Transfer reference defines the closing flags as setting Account.flags.closed when a pending transfer succeeds, without requiring the existing balance to be zero; balancing the account is a separate operation in the closing-entry recipe. A zero-amount closing pending transfer can therefore freeze an account with funds and be voided to reopen it. Correct this distinction and the earlier claim that no freeze primitive exists, so the design does not unnecessarily rely exclusively on gateway-side freezes.
Useful? React with 👍 / 👎.
| - Execution is single-threaded per object and requests to one object are | ||
| serialized, which is what makes the strong consistency cheap: no locks or | ||
| consensus are needed inside one user's store. For ID this matches the existing |
There was a problem hiding this comment.
Qualify the request-serialization guarantee across async calls
When a handler awaits an external operation such as fetch(), another request can execute on the same Durable Object and change its state; single-threaded execution does not serialize complete asynchronous handlers. Cloudflare's concurrency documentation explicitly distinguishes synchronous SQLite operations and storage input gates from external async calls that permit interleaving. The unconditional guarantee here could lead the proposed graph/journal or shared-world handlers to read state, await external work, and then commit updates against stale state. State that invariant-sensitive check/update sequences must remain synchronous or use explicit concurrency protection when spanning external awaits.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9995a56b2e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| would be two records of the same event, linked by storing the ID-graph object | ||
| ID in a transfer's `user_data_128` (128-bit, indexed) — the docs explicitly |
There was a problem hiding this comment.
Preserve the full graph ID in the reconciliation link
For the signed ID-graph events described here, the proposed direct link does not fit: pkgs/id/src/event_store/range.rs:36–37 defines event IDs as 32-byte BLAKE3 hashes, whereas TigerBeetle's user_data_128 holds only 16 bytes. Storing the full event ID in this field is therefore impossible, and truncating it would lose the reference needed to retrieve and verify the signed source. Specify a control-plane mapping from a 128-bit surrogate to the full hash, or another lossless representation, as part of the reconciliation design.
Useful? React with 👍 / 👎.
Adds the first two investigation reports of the 2026-10-28 ID platform expansion program (epic #2056), filed in doc/ following the repo's timestamped design-doc convention (pkgs/id/doc symlinks there):
These feed the currencies v1 synthesis (#2043) and the serverless edition v1 synthesis (#2046). Docs only; no code changes.
Need help on this PR? Tag
@codesmith-botwith what you need.