Gate 5 journal reconciliation detail#10
Conversation
|
Deployment failed with the following error: |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f079673baf
ℹ️ 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".
| readRowById('btd_asset_pack_ranges', 'asset_pack_id', assetPackId, readErrors), | ||
| readRowById('btc_fee_transactions', 'receipt_id', btcFeeReceiptId, readErrors), | ||
| readRowById('btd_asset_pack_ledger_anchors', 'anchor_id', ledgerAnchorId, readErrors), | ||
| readRowById('btd_ownership_events', 'ownership_event_id', ownershipEventId, readErrors), | ||
| readRowById('btd_read_licenses', 'license_id', readLicenseId, readErrors), |
There was a problem hiding this comment.
Restrict ledger readback to this run's facts
When a user can fetch a selected execution, these admin-client lookups trust the ledgerSettlement IDs stored in that execution and then return select('*') rows from global ledger tables. Because postExecutionHistoryRoute persists caller-supplied output/context for the user's own run, a caller can create a run whose assetPackId, btcFeeReceiptId, or other IDs point at another user's ledger facts and this route will bypass RLS via supabaseAdmin, exposing rows such as BTC fee wallet authorization/PSBT data and read-license wallet IDs. The readback should derive/verify ownership from the selected run's persisted settlement or constrain each lookup to facts created for that run/user before returning the rows.
Useful? React with 👍 / 👎.
| const { data, error } = await supabaseAdmin | ||
| .from('btd_ledger_database_reconciliation_repairs') | ||
| .select('*') | ||
| .order('issued_at', { ascending: false }) | ||
| .limit(100); |
There was a problem hiding this comment.
Filter reconciliation repairs before limiting
This query takes only the newest 100 repair receipts globally and filters for the selected run afterward. In any environment with more than 100 newer repairs from other runs, an older selected run's blocking repair will be omitted, causing the Terminal journal detail to show no repair/blocking reason even though the database contains one. Apply the runId/factIds predicates in the Supabase query before the limit, or page until all matching repairs are found.
Useful? React with 👍 / 👎.
Summary
Validation