Skip to content

feat: resolved frontend issues - #433

Merged
Jaydbrown merged 3 commits into
conduit-protocol:mainfrom
0xSlink:main
Aug 31, 2026
Merged

feat: resolved frontend issues#433
Jaydbrown merged 3 commits into
conduit-protocol:mainfrom
0xSlink:main

Conversation

@0xSlink

@0xSlink 0xSlink commented Aug 30, 2026

Copy link
Copy Markdown

Closes #368 — Key TokenAllowanceGateway records by owner::token::spender; call resetTokenAllowanceGateway() on disconnect/account-switch
Closes #367 — Concurrency queue entries store { resolve, reject }; reset() calls entry.reject(OperationAbortedError)
Closes #365
Closes #366 — Parallelize stream fetches (address batch + info/withdrawable in batches of 5); debounce visibility refetch (5s); surface partial errors with amber banner

…unt state leaks (conduit-protocol#368)

The singleton gateway keyed records by token+spender only, so switching
wallet accounts could return the previous account's cached allowance,
potentially skipping the approve step and causing create_stream to revert.

- Change _key to owner::token::spender triple
- Update _getOrCreate, getAllowance, approve, checkAllowance accordingly
- Call resetTokenAllowanceGateway() on disconnect and account switch
  in WalletContext (same places that call queryClient.clear())
…() (conduit-protocol#367)

reset() was resolving queued concurrency entries (calling entry() which
resolved the waiter with a release function), causing approve() calls to
proceed against a disconnected wallet after reset was called on
disconnect.

- Restructure queue entries to store { resolve, reject } callbacks
- Call entry.reject(OperationAbortedError) during reset drain
- Matches the comment's intended behavior: queued waiters are rejected
…onduit-protocol#365, conduit-protocol#366)

conduit-protocol#365 - N+1 serial fetch:
- Resolve all stream addresses in one Promise.allSettled batch
- Fetch info+withdrawable in bounded-parallel batches of 5
- Debounce visibilitychange refetch: skip if last fetch was <5s ago

conduit-protocol#366 - Silent data loss on fetch errors:
- Collect per-stream failures via failedCount in loadRows return
- Show amber partial-error banner when some streams fail to load
  (e.g. '3 streams could not be loaded — some data may be missing')
  with a Retry button, distinguishing partial failure from empty result
@drips-wave

drips-wave Bot commented Aug 30, 2026

Copy link
Copy Markdown

@0xSlink Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment