Bug: Transfer status page stuck at step 4 after successful withdraw_execute #106

New issue

Closed

opened 2026-04-10 04:15:29 +00:00 by Brouie · 15 comments

Brouie commented 2026-04-10 04:15:29 +00:00 (Migrated from gitlab.com)

Copy link

Mainnet v0.1.82 (7cb18b3 + operator hotfix 4/10)

BSC->Solana 0.995 testa nonce 41 (hash 0xf443ffa5d976107d...). Full flow completed -- tokens received in Backpack wallet (confirmed 0.995 testa SPL). But the transfer status page remains at step 4/5 (EXECUTE ON SOLANA active), never flips to step 5 COMPLETE. Waited 10+ minutes.

Likely cause: TransferStatusPage polls on-chain state via api.mainnet.solana.com (wallet default RPC) which returns 403. Frontend cannot detect the completed withdrawal. Related to #102 (SolanaRecipientExecutePanel RPC 403 issue).

Acceptance criteria:

• Transfer status page detects completed withdraw_execute and shows step 5 COMPLETE
• Polling uses bridge Connection RPC, not wallet default

Mainnet v0.1.82 (7cb18b3 + operator hotfix 4/10) BSC->Solana 0.995 testa nonce 41 (hash 0xf443ffa5d976107d...). Full flow completed -- tokens received in Backpack wallet (confirmed 0.995 testa SPL). But the transfer status page remains at step 4/5 (EXECUTE ON SOLANA active), never flips to step 5 COMPLETE. Waited 10+ minutes. Likely cause: TransferStatusPage polls on-chain state via api.mainnet.solana.com (wallet default RPC) which returns 403. Frontend cannot detect the completed withdrawal. Related to #102 (SolanaRecipientExecutePanel RPC 403 issue). Acceptance criteria: - [ ] Transfer status page detects completed withdraw_execute and shows step 5 COMPLETE - [ ] Polling uses bridge Connection RPC, not wallet default

Brouie commented 2026-04-10 04:20:16 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in issue #107

mentioned in issue #107

PlasticDigits commented 2026-04-13 03:58:08 +00:00 (Migrated from gitlab.com)

Copy link

@brouie Triage (repo main): TransferStatusPage already polls useMultiChainLookup → querySolanaPendingWithdraw with withSolanaReadFallback over merged bridge RPC URLs. We also extended useTransferStatusRefresh so homepage recent transfers poll Solana destinations the same way (parity with #106 / #102). Please re-test the status page and home badges on a current build; close if step 5 / lifecycle updates correctly after withdraw_execute.

@brouie Triage (repo `main`): `TransferStatusPage` already polls `useMultiChainLookup` → `querySolanaPendingWithdraw` with `withSolanaReadFallback` over merged bridge RPC URLs. We also extended `useTransferStatusRefresh` so **homepage** recent transfers poll Solana destinations the same way (parity with #106 / #102). Please re-test the status page and home badges on a current build; close if step 5 / lifecycle updates correctly after `withdraw_execute`.

PlasticDigits commented 2026-04-13 04:04:20 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in commit 5fc9eb4b50

mentioned in commit 5fc9eb4b50e3f654e9d29576efa861e375c956a0

Brouie commented 2026-04-13 05:02:45 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in issue #102

mentioned in issue #102

Brouie commented 2026-04-13 05:04:55 +00:00 (Migrated from gitlab.com)

Copy link

Retested on new deploy (main-CHZ1ahQz, 4/13). Active transfers (nonce 42, Approved state) now show full dest data on verify page -- RPC reads working. But completed transfers (nonce 41, already executed on 4/10) show 'HASH NOT SUBMITTED' with all dest fields blank. The pending-withdraw PDA is closed after execute, so there's no on-chain record left for the frontend to read. This is a design issue -- Solana has no post-execution state to query unlike EVM/Terra.

Retested on new deploy (main-CHZ1ahQz, 4/13). Active transfers (nonce 42, Approved state) now show full dest data on verify page -- RPC reads working. But completed transfers (nonce 41, already executed on 4/10) show 'HASH NOT SUBMITTED' with all dest fields blank. The pending-withdraw PDA is closed after execute, so there's no on-chain record left for the frontend to read. This is a design issue -- Solana has no post-execution state to query unlike EVM/Terra.

Brouie commented 2026-04-13 05:24:42 +00:00 (Migrated from gitlab.com)

Copy link

Confirmed again on 4/13 with BSC->Solana 1.99 testa nonce 43. Execute succeeded -- tokens received in Backpack (11.94 testa).

Hash: 0x52f4af7a5a1d01fd747342a0a22a0357f998928e3c7263c9da8989337cce39fa

Transfer status page: stuck at step 4/5, never advances to Complete.

Verify page: shows PENDING + 'Pending verification'. Source deposit data populated (nonce 43, amount 1990000000000000000, timestamp 4/13/2026 1:07:33 PM). All dest fields show dashes. 'HASH NOT SUBMITTED TO DESTINATION' even though withdrawSubmit, approval, and execute all succeeded.

Root cause: pending-withdraw PDA closes on execute, no on-chain record left for frontend to read. Affects both transfer status and verify pages for all completed Solana transfers. Confirmed on nonces 41 and 43.

Confirmed again on 4/13 with BSC->Solana 1.99 testa nonce 43. Execute succeeded -- tokens received in Backpack (11.94 testa). Hash: 0x52f4af7a5a1d01fd747342a0a22a0357f998928e3c7263c9da8989337cce39fa Transfer status page: stuck at step 4/5, never advances to Complete. Verify page: shows PENDING + 'Pending verification'. Source deposit data populated (nonce 43, amount 1990000000000000000, timestamp 4/13/2026 1:07:33 PM). All dest fields show dashes. 'HASH NOT SUBMITTED TO DESTINATION' even though withdrawSubmit, approval, and execute all succeeded. Root cause: pending-withdraw PDA closes on execute, no on-chain record left for frontend to read. Affects both transfer status and verify pages for all completed Solana transfers. Confirmed on nonces 41 and 43.

Brouie commented 2026-04-13 05:36:14 +00:00 (Migrated from gitlab.com)

Copy link

Additional finding: signatureSubscribe websocket returns malformed responses on every Solana transfer tested today. Console error: 'Server response malformed. Response must include either result or error, but not both.' This may be contributing to the step 4->5 detection failure -- the frontend subscribes to the execute tx signature but the subscription response is broken, so it never gets the confirmation callback.

Additional finding: signatureSubscribe websocket returns malformed responses on every Solana transfer tested today. Console error: 'Server response malformed. Response must include either result or error, but not both.' This may be contributing to the step 4->5 detection failure -- the frontend subscribes to the execute tx signature but the subscription response is broken, so it never gets the confirmation callback.

PlasticDigits commented 2026-04-13 12:58:06 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in commit f227b6fb64

mentioned in commit f227b6fb64fa2a8ef4f34aa1cac947f7e07b5372

PlasticDigits commented 2026-04-13 12:58:09 +00:00 (Migrated from gitlab.com)

Copy link

Update (signatureSubscribe / malformed WebSocket JSON-RPC)

Root cause for the console error "Server response malformed. Response must include either result or error, but not both" was in rpc-websockets (used by @solana/web3.js for Connection WebSockets). The library treated ("error" in msg) === ("result" in msg) as invalid. That is true when both keys exist — including error: null plus result, which some Solana RPCs return — so confirmTransaction / signature subscription could fail even though the tx succeeded.

Fix: packages/frontend/patches/rpc-websockets+9.3.3.patch — only reject when neither error nor result is present, and return after the malformed path so the queue is not settled twice. Regression tests: src/services/solana/jsonRpcWebsocketResponse.test.ts. README note in the frontend package.

Commit: f227b6f on main.

@brouie — please review the patch and re-test transfer status step 4→5 after deploy; the pending-withdraw PDA closed after execute issue remains a separate UX/data concern for verify/history, but this should unblock WebSocket confirmation when the RPC sends error: null alongside result.

Leaving open until you confirm on mainnet.

**Update (signatureSubscribe / malformed WebSocket JSON-RPC)** Root cause for the console error *"Server response malformed. Response must include either result or error, but not both"* was in **`rpc-websockets`** (used by `@solana/web3.js` for `Connection` WebSockets). The library treated `("error" in msg) === ("result" in msg)` as invalid. That is **true** when both keys exist — including **`error: null` plus `result`**, which some Solana RPCs return — so `confirmTransaction` / signature subscription could fail even though the tx succeeded. **Fix:** `packages/frontend/patches/rpc-websockets+9.3.3.patch` — only reject when **neither** `error` nor `result` is present, and **return** after the malformed path so the queue is not settled twice. Regression tests: `src/services/solana/jsonRpcWebsocketResponse.test.ts`. README note in the frontend package. **Commit:** f227b6f on `main`. @brouie — please review the patch and re-test transfer status step 4→5 after deploy; the **pending-withdraw PDA closed after execute** issue remains a separate UX/data concern for verify/history, but this should unblock WebSocket confirmation when the RPC sends `error: null` alongside `result`. Leaving **open** until you confirm on mainnet.

Brouie commented 2026-04-20 02:27:33 +00:00 (Migrated from gitlab.com)

Copy link

@PlasticDigits Retested on build f227b6f (websocket patch). 3 fresh transfers (BSC nonce 47, opBNB nonce 26, Terra nonce 59) all executed successfully -- tokens received in Backpack (19.6 testa). But UI still stuck at step 4/5 on all 3. signatureSubscribe malformed error still appearing in console. The websocket patch did not resolve the step detection issue.

@PlasticDigits Retested on build f227b6f (websocket patch). 3 fresh transfers (BSC nonce 47, opBNB nonce 26, Terra nonce 59) all executed successfully -- tokens received in Backpack (19.6 testa). But UI still stuck at step 4/5 on all 3. signatureSubscribe malformed error still appearing in console. The websocket patch did not resolve the step detection issue.

Brouie commented 2026-04-20 03:50:57 +00:00 (Migrated from gitlab.com)

Copy link

@PlasticDigits Re-test on build v0.1.82 - f227b6f (frontend bundle main-CvcBOh67), 4/20 mainnet. Providing complete debug payload per new standard.

Failing transfer (Solana destination) -- step 5 stuck

XChain Hash ID: 0x082a0e1b9884e276b7f8205e976bda32412d6dcb918e81b1e8e1668bcbc4fdef
Path: BSC -> Solana
Amount: 1.99 testa
Nonce: 47
Source TX: 0x9cb56f9c9483d99e14f1f25c479127c4e349e129c2553cb17311d5666b10867c
Recipient: 0xb0c8dccbb82263d1524de950d2e9d32af183d80636cc82713844803a3827a234
Wallet: Backpack (Cu6Q...aDBy)
Result: tokens received in wallet, UI stuck 1hr+ at step 4/5

UX state (step 4/5 stuck)

• STEP 4/5 badge top-right
• DEPOSIT: DONE
• SUBMIT HASH: DONE
• APPROVAL: DONE
• EXECUTE ON SOLANA: ACTIVE (still)
• COMPLETE: UP NEXT (never advances)
• CANCEL WINDOW ACTIVE banner still shown after 1hr+

Note: tokens confirmed delivered to Backpack immediately after execute sign. UI never reflects completion.

Console logs (Solana failing)

[autoWithdraw] canAutoSubmit=false, reason=syncing, transfer=tx-1776650753261-2xd5tll, nonce=47, lifecycle=deposited
[autoWithdraw] Auto-submit ready for transfer tx-1776650753261-2xd5tll
[autoWithdraw] triggerSubmit starting for transfer tx-1776650753261-2xd5tll, direction=evm-to-solana, nonce=47, amount=1990000000000000000
[autoWithdraw] Submitting Solana withdrawSubmit: program=4XX8ndYXupw4Sb4SsRgAPTmBJJjfZbg8rWjj87iKEhVt
[autoWithdraw] triggerSubmit error for transfer tx-1776650753261-2xd5tll: Signature 2q4VRBDZdsSj8GnPNr32sLTf1UHydtk6hRh1t6jqaijhQxDT9WetH9a7US1MCBJcaCNWrNuDnLobUJRX335upM8J has expired: block height exceeded.
Received error calling signatureSubscribe {args: Array(2), error: Error: Server response malformed. Response must include either "result" or "error", but not both.}
GET https://columbus-lcd.terra.dev/cosmos/bank/v1beta1/balances/.../by_denom?denom=uluna 500 (Internal Server Error)

Both the signatureSubscribe malformed error and block height exceeded still present after rpc-websockets+9.3.3.patch.

Passing transfer (EVM destination) -- clean step flip

XChain Hash ID: 0x63de51f92e688611b84f5f207bb01bd74730786d2d842f10d12e38038bde6074
Path: Terra -> BSC
Amount: 1.994 testa
Nonce: 60
Source TX: E63833E65A427C17428A33B0B2E0FEF4A85E04C2A0CBC1F1D56D8E11EE9726E5
Destination TX: 0xea5c94af24fa261afc0cabb8a776561f5779354cdc51898f5c0b90742d404699
Result: step 4/4 COMPLETE reached normally, cancel window visible with countdown (4:31 remaining)

Console logs (EVM passing)

[TransferForm:terra] Deposit success, txHash=E63833E65A...
[depositReceipt] Parsed tx: nonce=60, amount=1994000000000000000, xchainHashId=0x63de51f92e688611...
[autoWithdraw] canAutoSubmit=false, reason=syncing, transfer=tx-1776656883311-l12elzr, nonce=60, lifecycle=deposited
[autoWithdraw] Auto-submit ready
[autoWithdraw] triggerSubmit starting, direction=terra-to-evm
[autoWithdraw] Submitting EVM withdrawSubmit: bridge=0xb2a22c74da8e3642e0effc107d3ac362ce885369
[autoWithdraw] submitOnEvm success: txHash=0xea5c94af24fa261afc0cabb8a776561f5779354cdc51898f5c0b90742d404699

No signatureSubscribe errors, no block height exceeded. Clean sequential flow.

Structural observation

EVM destinations show 4 steps (COMPLETE = step 4). Solana destinations show 5 steps (COMPLETE = step 5, after EXECUTE ON SOLANA). The extra Solana step is the user-initiated withdraw_execute. Step 5 transition is where the UI hangs -- the PDA closes on execute and there's no post-execution on-chain state for the frontend to poll for COMPLETE detection. Additionally the signatureSubscribe websocket subscription for the execute tx doesn't fire a clean callback due to the malformed response issue.

Summary

• websocket patch did not resolve step 4 -> 5 detection
• tokens deliver successfully on all tested paths (BSC/opBNB/Terra -> Solana)
• UI never advances past step 4/5 for any Solana destination
• EVM destinations unaffected, step 4/4 flips cleanly

@PlasticDigits Re-test on build v0.1.82 - f227b6f (frontend bundle main-CvcBOh67), 4/20 mainnet. Providing complete debug payload per new standard. ## Failing transfer (Solana destination) -- step 5 stuck **XChain Hash ID:** 0x082a0e1b9884e276b7f8205e976bda32412d6dcb918e81b1e8e1668bcbc4fdef **Path:** BSC -> Solana **Amount:** 1.99 testa **Nonce:** 47 **Source TX:** 0x9cb56f9c9483d99e14f1f25c479127c4e349e129c2553cb17311d5666b10867c **Recipient:** 0xb0c8dccbb82263d1524de950d2e9d32af183d80636cc82713844803a3827a234 **Wallet:** Backpack (Cu6Q...aDBy) **Result:** tokens received in wallet, UI stuck 1hr+ at step 4/5 ### UX state (step 4/5 stuck) - STEP 4/5 badge top-right - DEPOSIT: DONE - SUBMIT HASH: DONE - APPROVAL: DONE - EXECUTE ON SOLANA: **ACTIVE** (still) - COMPLETE: UP NEXT (never advances) - CANCEL WINDOW ACTIVE banner still shown after 1hr+ Note: tokens confirmed delivered to Backpack immediately after execute sign. UI never reflects completion. ### Console logs (Solana failing) ``` [autoWithdraw] canAutoSubmit=false, reason=syncing, transfer=tx-1776650753261-2xd5tll, nonce=47, lifecycle=deposited [autoWithdraw] Auto-submit ready for transfer tx-1776650753261-2xd5tll [autoWithdraw] triggerSubmit starting for transfer tx-1776650753261-2xd5tll, direction=evm-to-solana, nonce=47, amount=1990000000000000000 [autoWithdraw] Submitting Solana withdrawSubmit: program=4XX8ndYXupw4Sb4SsRgAPTmBJJjfZbg8rWjj87iKEhVt [autoWithdraw] triggerSubmit error for transfer tx-1776650753261-2xd5tll: Signature 2q4VRBDZdsSj8GnPNr32sLTf1UHydtk6hRh1t6jqaijhQxDT9WetH9a7US1MCBJcaCNWrNuDnLobUJRX335upM8J has expired: block height exceeded. Received error calling signatureSubscribe {args: Array(2), error: Error: Server response malformed. Response must include either "result" or "error", but not both.} GET https://columbus-lcd.terra.dev/cosmos/bank/v1beta1/balances/.../by_denom?denom=uluna 500 (Internal Server Error) ``` Both the signatureSubscribe malformed error and block height exceeded still present after rpc-websockets+9.3.3.patch. ## Passing transfer (EVM destination) -- clean step flip **XChain Hash ID:** 0x63de51f92e688611b84f5f207bb01bd74730786d2d842f10d12e38038bde6074 **Path:** Terra -> BSC **Amount:** 1.994 testa **Nonce:** 60 **Source TX:** E63833E65A427C17428A33B0B2E0FEF4A85E04C2A0CBC1F1D56D8E11EE9726E5 **Destination TX:** 0xea5c94af24fa261afc0cabb8a776561f5779354cdc51898f5c0b90742d404699 **Result:** step 4/4 COMPLETE reached normally, cancel window visible with countdown (4:31 remaining) ### Console logs (EVM passing) ``` [TransferForm:terra] Deposit success, txHash=E63833E65A... [depositReceipt] Parsed tx: nonce=60, amount=1994000000000000000, xchainHashId=0x63de51f92e688611... [autoWithdraw] canAutoSubmit=false, reason=syncing, transfer=tx-1776656883311-l12elzr, nonce=60, lifecycle=deposited [autoWithdraw] Auto-submit ready [autoWithdraw] triggerSubmit starting, direction=terra-to-evm [autoWithdraw] Submitting EVM withdrawSubmit: bridge=0xb2a22c74da8e3642e0effc107d3ac362ce885369 [autoWithdraw] submitOnEvm success: txHash=0xea5c94af24fa261afc0cabb8a776561f5779354cdc51898f5c0b90742d404699 ``` No signatureSubscribe errors, no block height exceeded. Clean sequential flow. ## Structural observation EVM destinations show **4 steps** (COMPLETE = step 4). Solana destinations show **5 steps** (COMPLETE = step 5, after EXECUTE ON SOLANA). The extra Solana step is the user-initiated withdraw_execute. Step 5 transition is where the UI hangs -- the PDA closes on execute and there's no post-execution on-chain state for the frontend to poll for COMPLETE detection. Additionally the signatureSubscribe websocket subscription for the execute tx doesn't fire a clean callback due to the malformed response issue. ## Summary - websocket patch did not resolve step 4 -> 5 detection - tokens deliver successfully on all tested paths (BSC/opBNB/Terra -> Solana) - UI never advances past step 4/5 for any Solana destination - EVM destinations unaffected, step 4/4 flips cleanly

Brouie commented 2026-04-20 04:49:42 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in issue #110

mentioned in issue #110

Brouie commented 2026-04-20 05:35:47 +00:00 (Migrated from gitlab.com)

Copy link

mentioned in issue #111

mentioned in issue #111

PlasticDigits commented 2026-04-20 05:55:32 +00:00 (Migrated from gitlab.com)

Copy link

Fix landed on main (commit f554a52)

Root cause

On Solana, withdraw_execute closes the PendingWithdraw PDA (rent returned to the recipient) and creates an ExecutedHash marker account so the hash cannot be reused. The frontend only queried PendingWithdraw via querySolanaPendingWithdraw. After a successful execute, that account is gone, so the RPC returned null and the UI never treated the transfer as finished — even when tokens had already arrived. This matches the stuck step 4/5 behavior independent of which RPC is used for the read.

What we changed

• packages/frontend/src/services/solana/solanaBridgeQueries.ts: if PendingWithdraw is missing, we derive the ["executed", hash] PDA and, when the account exists and matches the Anchor ExecutedHash layout, we return a synthetic PendingWithdrawData with executed: true so useMultiChainLookup, useTransferStatusRefresh, useApprovalCountdown, and TransferStatusPage can advance lifecycle to completed.
• Added packages/frontend/src/services/solana/solanaBridgeQueries.test.ts (discriminator checks for the executed marker).

Related

• Issue description also mentioned 403 on api.mainnet.solana.com and using bridge RPCs — that is still worth tracking for wallet-driven paths (#102), but the completion detection gap above was the structural reason the stepper could stay on “Execute on Solana” forever after a good execute.

@Brouie — can you verify on mainnet after the next frontend deploy that a BSC → Solana transfer reaches step 5 COMPLETE once withdraw_execute succeeds? If anything still fails, a concrete xchain hash + wallet RPC in use would help narrow RPC vs UI.

### Fix landed on `main` (commit f554a52) **Root cause** On Solana, `withdraw_execute` **closes** the `PendingWithdraw` PDA (rent returned to the recipient) and creates an **`ExecutedHash`** marker account so the hash cannot be reused. The frontend only queried `PendingWithdraw` via `querySolanaPendingWithdraw`. After a successful execute, that account is **gone**, so the RPC returned `null` and the UI never treated the transfer as finished — even when tokens had already arrived. This matches the stuck step 4/5 behavior independent of which RPC is used for the read. **What we changed** - `packages/frontend/src/services/solana/solanaBridgeQueries.ts`: if `PendingWithdraw` is missing, we derive the `["executed", hash]` PDA and, when the account exists and matches the Anchor `ExecutedHash` layout, we return a **synthetic** `PendingWithdrawData` with `executed: true` so `useMultiChainLookup`, `useTransferStatusRefresh`, `useApprovalCountdown`, and `TransferStatusPage` can advance lifecycle to **completed**. - Added `packages/frontend/src/services/solana/solanaBridgeQueries.test.ts` (discriminator checks for the executed marker). **Related** - Issue description also mentioned **403** on `api.mainnet.solana.com` and using bridge RPCs — that is still worth tracking for wallet-driven paths (#102), but the **completion detection** gap above was the structural reason the stepper could stay on “Execute on Solana” forever after a good execute. @Brouie — can you **verify on mainnet** after the next frontend deploy that a **BSC → Solana** transfer reaches step **5 COMPLETE** once `withdraw_execute` succeeds? If anything still fails, a concrete xchain hash + wallet RPC in use would help narrow RPC vs UI.

Brouie commented 2026-04-20 06:28:07 +00:00 (Migrated from gitlab.com)

Copy link

@PlasticDigits Fix verified on build v0.1.82 - dae31d3 (frontend bundle main-CSMgjCa4), 4/20 mainnet.

Fresh BSC -> Solana testa 1.99 test:

XChain Hash ID: 0x3a9cd67d15d34b9e0bed012e3615770b160fd9c596d62c132535a7be3a0c34c2
Source TX (BSC): 0x5a6ca5771b4e70863085babdb6d7d70ddd24aa49c8d3451c4a81ba010ffba96f
Recipient: 0xb0c8dccbb82263d1524de950d2e9d32af183d80636cc82713844803a3827a234
Nonce: 49
Result: All 5 steps flipped through to COMPLETE automatically

UX state after execute:

• STEP 5/5
• DEPOSIT: DONE
• SUBMIT HASH: DONE
• APPROVAL: DONE
• EXECUTE ON SOLANA: DONE (was stuck at ACTIVE pre-fix)
• COMPLETE: DONE (never reached pre-fix)
• 'TRANSFER COMPLETE - Tokens have been delivered to the recipient address' banner

Commit f554a52 (detect Solana transfer completion via ExecutedHash PDA) resolves the step 4 -> 5 hang. ExecutedHash PDA polling now provides the completion signal, bypassing the broken websocket subscription. History tab also confirms -- all Solana-destination transfers in recent history now show 'Complete' badge (previously stuck at 'Approved').

Note: signatureSubscribe malformed and block height exceeded errors still present in console but no longer block completion detection. Those are cosmetic and can be tracked separately if needed.

Closing #106.

@PlasticDigits Fix verified on build v0.1.82 - dae31d3 (frontend bundle main-CSMgjCa4), 4/20 mainnet. **Fresh BSC -> Solana testa 1.99 test:** **XChain Hash ID:** 0x3a9cd67d15d34b9e0bed012e3615770b160fd9c596d62c132535a7be3a0c34c2 **Source TX (BSC):** 0x5a6ca5771b4e70863085babdb6d7d70ddd24aa49c8d3451c4a81ba010ffba96f **Recipient:** 0xb0c8dccbb82263d1524de950d2e9d32af183d80636cc82713844803a3827a234 **Nonce:** 49 **Result:** All 5 steps flipped through to COMPLETE automatically **UX state after execute:** - STEP 5/5 - DEPOSIT: DONE - SUBMIT HASH: DONE - APPROVAL: DONE - EXECUTE ON SOLANA: DONE (was stuck at ACTIVE pre-fix) - COMPLETE: DONE (never reached pre-fix) - 'TRANSFER COMPLETE - Tokens have been delivered to the recipient address' banner Commit f554a52 (detect Solana transfer completion via ExecutedHash PDA) resolves the step 4 -> 5 hang. ExecutedHash PDA polling now provides the completion signal, bypassing the broken websocket subscription. History tab also confirms -- all Solana-destination transfers in recent history now show 'Complete' badge (previously stuck at 'Approved'). Note: signatureSubscribe malformed and block height exceeded errors still present in console but no longer block completion detection. Those are cosmetic and can be tracked separately if needed. Closing #106.

Brouie (Migrated from gitlab.com) closed this issue 2026-04-20 06:28:12 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

issue/165

issue/187

issue/170

issue/195

renovate/configure

review/brouie-solana-e2e-70

Labels

Clear labels   

agent:implement

Queue implement gate

  

agent:ready

  

backend

  

bug

  

cannot-reproduce

  

confirmed

  

desktop

  

docs

  

documentation

  

duplicate

  

enhancement

  

feature

  

frontend

  

good first issue

  

help wanted

  

high-risk

  

in-review

  

invalid

  

mobile

  

needs-triage

  

P0-critical

  

P1-high

  

P2-medium

  

P3-low

  

qa

  

QA

  

question

  

ready

Definition of Ready

  

report

  

responsive

  

security

  

security-escalate

  

smart-contract

  

solana

  

tablet

  

test-pass

  

ux

  

wallet-issue

  

wallet:keplr

  

wallet:metamask

  

wallet:station

  

wallet:walletconnect

  

wontfix

No labels

agent:implement

agent:ready

backend

bug

cannot-reproduce

confirmed

desktop

docs

documentation

duplicate

enhancement

feature

frontend

good first issue

help wanted

high-risk

in-review

invalid

mobile

needs-triage

P0-critical

P1-high

P2-medium

P3-low

qa

QA

question

ready

report

responsive

security

security-escalate

smart-contract

solana

tablet

test-pass

ux

wallet-issue

wallet:keplr

wallet:metamask

wallet:station

wallet:walletconnect

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

code/cl8y-bridge-monorepo#106

No description provided.