fix: add on-chain fallback to bridge status when indexer returns nothing (fixes #37, #50)#51
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| } | ||
| // In mempool but not mined | ||
| return Ok(OnChainStatus::NotFound); | ||
| } |
There was a problem hiding this comment.
Pending mempool transaction misreported as "not found"
Medium Severity
When a transaction is in the mempool but not yet mined, eth_getTransactionByHash returns a result (line 79 check passes), yet line 83 still returns OnChainStatus::NotFound. The NotFound message then tells the user "Transaction not found on Ethereum mainnet" and suggests "The tx hash is incorrect" — which is wrong and alarming. The transaction exists and is simply pending. This defeats the PR's stated goal of giving users accurate feedback about their funds.
Additional Locations (1)
| chrono = "0.4" | ||
| dirs = "6" | ||
| rustyline = "15" | ||
| ethers = { version = "2.0", default-features = false, features = ["abigen"] } |
There was a problem hiding this comment.
Unused ethers dependency adds unnecessary bloat
Medium Severity
The ethers crate is added as a dependency but is never imported or used anywhere in the source code. The on-chain verification in bridge_verify.rs uses raw reqwest JSON-RPC calls instead. ethers is a heavy crate with dozens of transitive dependencies (visible in the Cargo.lock additions), significantly increasing compile time and binary size for no benefit.
| .map_err(|e| anyhow!("Failed to parse RPC response: {}", e))?; | ||
|
|
||
| Ok(json) | ||
| } |
There was a problem hiding this comment.
JSON-RPC errors silently misinterpreted as "not found"
Medium Severity
The rpc_call function never checks for a JSON-RPC "error" field in the response body. If the RPC node returns an error (e.g. rate-limiting, server overload) with HTTP 200 but a JSON-RPC error payload, receipt["result"] will be Value::Null, causing the code to fall through to OnChainStatus::NotFound. A confirmed transaction could be misreported as "not found" simply because the RPC returned an error — directly undermining the feature's purpose of giving users accurate on-chain status.
Additional Locations (1)
1 participant
Hey! First off, thanks for building this CLI — it's been really useful for interacting with Polymarket from the terminal.
I ran into the issue described in #37 and #50 where bridge status shows "No transactions found" even after a transaction is fully confirmed on Ethereum. It's a confusing experience because there's no way to tell if your funds are actually lost or if the backend just hasn't caught up yet.
The root cause is that the CLI only asks the Polymarket backend — so if the indexer is delayed or temporarily down, the user gets no useful feedback even though their funds are sitting safely on-chain.
I added an optional --tx-hash flag to the bridge status command. When the backend returns nothing and the user provides their Ethereum tx hash, the CLI independently checks the transaction on-chain via a public Ethereum RPC and tells them what's actually happening.
If the transaction is confirmed on-chain, the user sees the block number, confirmation count, and a clear message that their funds are safe and the indexer just needs more time. If the transaction genuinely failed or wasn't found, they get told that too with a link to Etherscan.
I tested this manually with a real transaction and it works correctly. Happy to make any changes if needed.
Fixes #37
Fixes #50
Note
Medium Risk
Adds a new network-path codepath that calls a public Ethereum JSON-RPC endpoint and changes
bridge statusbehavior/exit codes when the backend returns no transactions. Risk is mostly around RPC availability/timeouts and user-facing output/JSON compatibility, not core auth or funds movement.Overview
When
polymarket bridge statusreturns no transactions from the Polymarket backend, the CLI now offers an optional on-chain fallback via--tx-hashto verify the Ethereum transaction directly.This introduces
bridge_verify(new module) that performs JSON-RPC calls (eth_getTransactionReceipt,eth_blockNumber,eth_getTransactionByHash) against a public RPC, then prints a clear confirmed/failed/not-found message (or emits a JSON object in--output json). Dependencies were updated to includereqwestandethers(and lockfile changes) to support this flow.Written by Cursor Bugbot for commit 5410032. This will update automatically on new commits. Configure here.