Skip to content

feat: view bridge transaction history#1317

Merged
MicBun merged 16 commits intomainfrom
queryHistory
Feb 13, 2026
Merged

feat: view bridge transaction history#1317
MicBun merged 16 commits intomainfrom
queryHistory

Conversation

@MicBun
Copy link
Member

@MicBun MicBun commented Feb 13, 2026

resolves: https://github.com/truflation/website/issues/3309

Summary by CodeRabbit

  • New Features
    • Added transaction history query functionality for ERC20 bridge operations, enabling users to retrieve deposits, transfers, and withdrawals with transaction details and statuses across supported bridge networks.

@MicBun MicBun self-assigned this Feb 13, 2026
@MicBun MicBun added the type: feat New feature or request label Feb 13, 2026
@coderabbitai
Copy link

coderabbitai bot commented Feb 13, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Updates go.mod dependencies for kwil-db modules and introduces four SQL history action views (hoodi_tt_get_history, hoodi_tt2_get_history, sepolia_get_history, ethereum_get_history) to expose unified ERC20 bridge transaction history with corresponding end-to-end test coverage.

Changes

Cohort / File(s) Summary
Dependency Updates
go.mod
Bumps github.com/trufnetwork/kwil-db and github.com/trufnetwork/kwil-db/core to newer pseudoversions (from Feb 1 to Feb 13, 2026).
SQL Bridge History Actions
internal/migrations/erc20-bridge/005-history-actions.sql
Adds four new public view actions for ERC20 bridge history retrieval across hoodi_tt, hoodi_tt2, sepolia, and ethereum bridges, each returning unified history with transaction type, amount, addresses, hashes, status, and block information.
Bridge History Tests
tests/extensions/erc20/erc20_bridge_history_test.go
New end-to-end test validating bridge history functionality including deposit injection, internal transfer, and withdrawal operations with assertions on record counts, ordering, amounts, and statuses.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

Suggested reviewers

  • pr-time-tracker

Poem

🐰 A rabbit hops through history's row,
Four bridges built from high to low,
With deposits, transfers, withdrawals too—
The ledger's truth now shines right through!
🌉✨

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the main change: adding SQL actions to expose unified history for ERC20 bridge transactions, along with supporting tests and dependency updates.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Merge Conflict Detection ✅ Passed ✅ No merge conflicts detected when merging into main

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch queryHistory

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@holdex
Copy link

holdex bot commented Feb 13, 2026

Time Submission Status

Member Status Time Action Last Update
MicBun ✅ Submitted 5h 30min Update time Feb 13, 2026, 4:20 PM

You can submit time with the command. Example:

@holdex pr submit-time 15m

See available commands to help comply with our Guidelines.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@tests/extensions/erc20/erc20_bridge_history_test.go`:
- Line 34: The test currently discards errors from types.ParseDecimalExplicit
when creating transferAmt (and withdrawalAmt later), which can cause nil-pointer
panics; update the test to capture the returned error and assert it succeeded
using require.NoError(err) immediately after calling types.ParseDecimalExplicit
for transferAmt and withdrawalAmt so the test fails with a clear assertion
instead of panicking (keep the variables transferAmt/withdrawalAmt and the calls
to types.ParseDecimalExplicit unchanged, just add the require.NoError checks).
🧹 Nitpick comments (3)
internal/migrations/erc20-bridge/005-history-actions.sql (1)

1-86: Consider whether the pass-through wrapper pattern can be avoided.

All four actions are identical except for the delegated source (hoodi_tt, hoodi_tt2, sepolia_bridge, ethereum_bridge). If the SQL action language supports any form of dynamic dispatch or macro, that would eliminate maintaining four copies of the same column list and loop body. If not, this is fine as-is — just be aware that any schema change to the underlying get_history return type will require updating all four actions in lockstep.

tests/extensions/erc20/erc20_bridge_history_test.go (2)

52-70: Magic column indices (0, 1, 6, 7) are fragile and hard to read.

If the schema of get_history ever changes column order or adds/removes a column, every index here silently shifts. Consider introducing named constants or a small helper that maps row.Values into a struct, e.g.:

type historyRecord struct {
    Type               string
    Amount             *types.Decimal
    // ...
    Status             string
    BlockHeight        int64
}

This would make the assertions self-documenting and resilient to schema changes.


88-88: withdrawalRecipient duplicates TestEscrowA.

The hardcoded address "0x1111111111111111111111111111111111111111" is the same as TestEscrowA defined in common_test.go. Using TestEscrowA directly (or a distinct address) would make the intent clearer — is withdrawing to the escrow address itself intentional, or should a different external address be used?

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@tests/extensions/erc20/erc20_bridge_history_test.go`:
- Line 90: The test sets withdrawalRecipient to the same value as the escrow
address (hard-coded "0x111...1111" which equals TestEscrowA), so update the test
to use a distinct external address (e.g., TestUserB or another test constant) to
ensure the test exercises recipient-vs-escrow behavior; locate the declaration
of withdrawalRecipient in tests/extensions/erc20/erc20_bridge_history_test.go
and replace the hard-coded escrow value with the distinct test address constant
(referencing TestUserB or a similarly named constant from common_test.go).
🧹 Nitpick comments (2)
tests/extensions/erc20/erc20_bridge_history_test.go (2)

54-71: Magic column indices make assertions fragile and skip key fields.

The test accesses row values by positional index ([0], [1], [6], [7]) with no guard that the column schema matches expectations. If the view's column order changes, these assertions will silently check the wrong fields. Additionally, indices [2][5] (from/to address, tx hashes) are never asserted, reducing confidence in the history records' correctness.

Consider either:

  • Extracting named constants for column positions, or
  • Adding at least a column-count assertion (require.Len(t, transferRow, expectedCols)) to catch schema drift early, along with basic assertions on the skipped fields.

42-51: get_history parameters lack documentation — verify semantics.

The call passes (TestUserA, int64(10), int64(0)). From context this appears to be (address, limit, offset), but there's no comment clarifying the parameter contract. If the second param is actually a block-height filter rather than a limit, the test could be passing by coincidence (10 ≥ all block heights used). A brief inline comment would prevent misreads.

@MicBun MicBun merged commit 821ab0e into main Feb 13, 2026
7 checks passed
@MicBun MicBun deleted the queryHistory branch February 13, 2026 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: feat New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

Comments