bug: Monitor & Review hashes show Pending status even when complete or failed

PlasticDigits commented

2026-03-09 13:12:22 +00:00

(Migrated from gitlab.com)

Frontend Bug Report

Issue Title

bug: Monitor & Review hashes show Pending status even when complete or failed

Environment

Device Type: Desktop
Device Model: N/A
OS Version: Linux
Browser Version: Chrome (latest)
Wallet Used: N/A
Network / Chain: N/A (UI behavior)
Page: Verify

Steps to Reproduce

Navigate to the Verify page (/verify)
Scroll down to the "Monitor & Review" section where hashes are listed
Observe the status displayed next to each hash
Note that hashes which have already completed or failed still show "Pending" status

Expected Behavior

Hashes should display their actual status (e.g., "Complete" or "Failed") reflecting the real state of the transaction

Actual Behavior

All hashes in the Monitor & Review section show "Pending" status regardless of whether the transaction is complete or has failed

Severity

Medium

Evidence (screenshots / recordings)

N/A

Console Errors (if available)

# N/A

Transaction Hash (if applicable)

N/A

Source

Found during manual QA testing
Reported by a user

## Frontend Bug Report ### Issue Title - bug: Monitor & Review hashes show Pending status even when complete or failed ### Environment - Device Type: Desktop - Device Model: N/A - OS Version: Linux - Browser Version: Chrome (latest) - Wallet Used: N/A - Network / Chain: N/A (UI behavior) - Page: Verify ### Steps to Reproduce 1. Navigate to the Verify page (`/verify`) 2. Scroll down to the "Monitor & Review" section where hashes are listed 3. Observe the status displayed next to each hash 4. Note that hashes which have already completed or failed still show "Pending" status ### Expected Behavior - Hashes should display their actual status (e.g., "Complete" or "Failed") reflecting the real state of the transaction ### Actual Behavior - All hashes in the Monitor & Review section show "Pending" status regardless of whether the transaction is complete or has failed ### Severity - Medium ### Evidence (screenshots / recordings) - N/A ### Console Errors (if available) ```shell # N/A ``` ### Transaction Hash (if applicable) - N/A ### Source - [ ] Found during manual QA testing - [x] Reported by a user

PlasticDigits commented

2026-03-10 06:07:43 +00:00

(Migrated from gitlab.com)

Fix committed: `f71db17`

fix: resolve execution status for deposit-only hashes in Monitor & Review

Changes in this commit:

packages/frontend/src/services/hashMonitor.ts — After the initial deposit/withdraw merge phase, a new resolution step queries getPendingWithdraw(hash) on EVM destination chains and pending_withdraw on Cosmos destination chains to populate executed/cancelled/approved flags for deposit-only entries. Previously these entries always showed PENDING because EVM executed withdrawals are removed from getPendingWithdrawHashes (the enumerable set) and deposit events carry no execution flags. The mapping data (pendingWithdraws[hash]) is still available and now queried directly.
packages/contracts-terraclassic/bridge/src/query.rs — Added TODO comment on query_pending_withdrawals to remove executed/cancelled entries from PENDING_WITHDRAWS storage in a future update (mirroring EVM's _pendingWithdrawHashes.remove()).

This should resolve the remaining 40/42 hashes that were still showing PENDING in the All view. Leaving issue open for QA verification.

### Fix committed: f71db17 **`fix: resolve execution status for deposit-only hashes in Monitor & Review`** Changes in this commit: - **`packages/frontend/src/services/hashMonitor.ts`** — After the initial deposit/withdraw merge phase, a new resolution step queries `getPendingWithdraw(hash)` on EVM destination chains and `pending_withdraw` on Cosmos destination chains to populate `executed`/`cancelled`/`approved` flags for deposit-only entries. Previously these entries always showed PENDING because EVM executed withdrawals are removed from `getPendingWithdrawHashes` (the enumerable set) and deposit events carry no execution flags. The mapping data (`pendingWithdraws[hash]`) is still available and now queried directly. - **`packages/contracts-terraclassic/bridge/src/query.rs`** — Added TODO comment on `query_pending_withdrawals` to remove executed/cancelled entries from `PENDING_WITHDRAWS` storage in a future update (mirroring EVM's `_pendingWithdrawHashes.remove()`). This should resolve the remaining 40/42 hashes that were still showing PENDING in the All view. Leaving issue open for QA verification.

PlasticDigits commented

2026-03-10 06:11:36 +00:00

(Migrated from gitlab.com)

Ready to verify in 0.1.54+

PlasticDigits commented

2026-03-11 05:19:26 +00:00

(Migrated from gitlab.com)

@brouie If verified please close, otherwise comment remaining outstanding problems

`@brouie` If verified please close, otherwise comment remaining outstanding problems

PlasticDigits commented

2026-03-11 06:11:07 +00:00

(Migrated from gitlab.com)

assigned to @Brouie

Brouie commented

2026-03-12 01:38:43 +00:00

(Migrated from gitlab.com)

Reminder: New transactions correctly show VERIFIED status. 32 older hashes still show PENDING. The inferStatus fix works for entries with executed=true flag, but the monitor fetch does not populate executed flag for older entries. May need a one-time re-check of old hashes against on-chain state.

PlasticDigits commented

2026-03-12 07:21:43 +00:00

(Migrated from gitlab.com)

mentioned in commit 2dc9c8fe80

mentioned in commit 2dc9c8fe806d7064e2447ce5152cf21a43762b67

PlasticDigits commented

2026-03-12 07:21:57 +00:00

(Migrated from gitlab.com)

Fix pushed: `fix/issue-47-pending-hash-recheck` (`2dc9c8f`)

fix: periodic recheck of pending hashes and mark invalid as not-found

Root cause: the monitor fetched hashes on page load and resolved execution status only for entries with a known destChainBytes4. Older deposits (and entries without destination metadata) were never rechecked, so they stayed PENDING even after the withdrawal was executed on-chain.

Changes

hashMonitor.ts — resolveDepositExecutionStatus now brute-forces all configured chains (BSC, opBNB, Terra) for entries missing destChainBytes4. New recheckPendingHashes() export queries every chain for a list of pending hashes and returns execution/cancellation status or a notFound flag.
useHashMonitor.ts — Added a 30-second periodic interval that calls recheckPendingHashes() for all hashes still showing PENDING. Updates are applied in-place without a full page refetch. Hashes not found on any chain are marked as unknown (displayed as "Not Found").
HashMonitorSection.tsx — Added a "Not Found" filter tab. Refresh button shows "Rechecking…" during background checks.

This should resolve all 32 remaining PENDING hashes — they will auto-update to VERIFIED within one recheck cycle (≤30s) after page load.

@brouie Please verify on the deployed build:

Previously-stuck PENDING hashes now show VERIFIED after ~30s
New transfers still show correct PENDING → VERIFIED lifecycle
"Not Found" filter shows any hashes that don't exist on any chain
No regressions in the Verify page behavior

If verified, please close the issue.

### Fix pushed: `fix/issue-47-pending-hash-recheck` (2dc9c8f) **`fix: periodic recheck of pending hashes and mark invalid as not-found`** Root cause: the monitor fetched hashes on page load and resolved execution status only for entries with a known `destChainBytes4`. Older deposits (and entries without destination metadata) were never rechecked, so they stayed PENDING even after the withdrawal was executed on-chain. #### Changes 1. **`hashMonitor.ts`** — `resolveDepositExecutionStatus` now brute-forces all configured chains (BSC, opBNB, Terra) for entries missing `destChainBytes4`. New `recheckPendingHashes()` export queries every chain for a list of pending hashes and returns execution/cancellation status or a `notFound` flag. 2. **`useHashMonitor.ts`** — Added a 30-second periodic interval that calls `recheckPendingHashes()` for all hashes still showing PENDING. Updates are applied in-place without a full page refetch. Hashes not found on any chain are marked as `unknown` (displayed as "Not Found"). 3. **`HashMonitorSection.tsx`** — Added a "Not Found" filter tab. Refresh button shows "Rechecking…" during background checks. This should resolve all 32 remaining PENDING hashes — they will auto-update to VERIFIED within one recheck cycle (≤30s) after page load. @brouie Please verify on the deployed build: - [ ] Previously-stuck PENDING hashes now show VERIFIED after ~30s - [ ] New transfers still show correct PENDING → VERIFIED lifecycle - [ ] "Not Found" filter shows any hashes that don't exist on any chain - [ ] No regressions in the Verify page behavior If verified, please close the issue.

Brouie commented

2026-03-13 02:08:11 +00:00

(Migrated from gitlab.com)

Verified on deployed build (2026-03-13):

[✓] Previously-stuck PENDING hashes now show VERIFIED — all 32 resolved
[✓] Recent transfers (BSC→Terra, Terra→BSC, Terra→opBNB from 3/12) show correct lifecycle
[✓] Not Found filter tab present and functional
[✓] No regressions on Verify page

All hashes showing VERIFIED. Fix confirmed working.

Verified on deployed build (2026-03-13): [✓] Previously-stuck PENDING hashes now show VERIFIED — all 32 resolved [✓] Recent transfers (BSC→Terra, Terra→BSC, Terra→opBNB from 3/12) show correct lifecycle [✓] Not Found filter tab present and functional [✓] No regressions on Verify page All hashes showing VERIFIED. Fix confirmed working.

Brouie (Migrated from gitlab.com) closed this issue

2026-03-13 02:08:13 +00:00

Brouie commented

2026-03-13 04:17:48 +00:00

(Migrated from gitlab.com)

mentioned in issue #55