UI: Trade page pair selector reverts to EMBER/CORAL after selecting a different pair

totdking commented

2026-06-09 13:45:44 +00:00

(Migrated from gitlab.com)

No description provided.

totdking commented

2026-06-09 13:52:13 +00:00

(Migrated from gitlab.com)

Summary

On the /trade page, the pair selector dropdown opens correctly when clicked and displays available pairs. However, selecting any pair other than the default EMBER/CORAL causes the selector to immediately revert back to EMBER/CORAL. The selected pair is not retained and the trade panel does not update to reflect the new pair.

Reproduction steps

Navigate to /trade on LocalTerra
Click the pair selector (shows EMBER/CORAL by default)
Observe: dropdown opens with available pairs listed
Select any pair other than EMBER/CORAL
Observe: selector reverts back to EMBER/CORAL; the trade panel does not change

Expected behavior

Selecting a pair from the dropdown should update the trade panel to show order book, price, and order ticket for the newly selected pair. The selector should retain the chosen pair.

Actual behavior

The dropdown closes after selection but the pair immediately reverts to EMBER/CORAL. No state change is persisted. The user cannot trade any pair other than the default on this page.

Impact assessment

Users are locked to the EMBER/CORAL pair on the trade page regardless of selection
Effectively blocks all trading activity on any other pair via the trade route
High severity as it prevents a core trading flow from functioning

Environment

Chain: localterra
LCD: http://localhost:1317
Wallet: Keplr (Terra Classic)
Browser: Chromium
Page: /trade

Severity: ~"blocker:hybrid" -- users cannot switch pairs on the trade page.

ref to https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/301 still prevalent, found during exploratory testing of VP-4 of checklist https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/291

cc: @PlasticDigits

### Summary On the `/trade` page, the pair selector dropdown opens correctly when clicked and displays available pairs. However, selecting any pair other than the default EMBER/CORAL causes the selector to immediately revert back to EMBER/CORAL. The selected pair is not retained and the trade panel does not update to reflect the new pair. --- ### Reproduction steps 1. Navigate to `/trade` on LocalTerra 2. Click the pair selector (shows EMBER/CORAL by default) 3. Observe: dropdown opens with available pairs listed 4. Select any pair other than EMBER/CORAL 5. Observe: selector reverts back to EMBER/CORAL; the trade panel does not change --- ### Expected behavior Selecting a pair from the dropdown should update the trade panel to show order book, price, and order ticket for the newly selected pair. The selector should retain the chosen pair. --- ### Actual behavior The dropdown closes after selection but the pair immediately reverts to EMBER/CORAL. No state change is persisted. The user cannot trade any pair other than the default on this page. --- ### Impact assessment - Users are locked to the EMBER/CORAL pair on the trade page regardless of selection - Effectively blocks all trading activity on any other pair via the trade route - High severity as it prevents a core trading flow from functioning --- ### Environment - Chain: localterra - LCD: [http://localhost:1317](http://localhost:1317) - Wallet: Keplr (Terra Classic) - Browser: Chromium - Page: `/trade` --- **Severity:** ~"blocker:hybrid" -- users cannot switch pairs on the trade page. ref to https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/301 still prevalent, found during exploratory testing of VP-4 of checklist https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/291 **cc:** @PlasticDigits

Brouie commented

2026-06-10 01:24:05 +00:00

(Migrated from gitlab.com)

Triaged this from source + git history + the unit layer (browser re-check is batched for my next frontend pass).

Good news first: this is NOT the #301 fix regressing. TradePage.tsx hasn't been touched since the PairSearchSelect change landed, nothing in the recent wave goes near the selector files, and the #301 regression tests (the real portal-click path) are green at 83dc192. The mouse-click flow is correct at current main.

But there IS a deterministic bug at current main in the type-then-Enter flow, and it produces exactly this symptom:

typing a query force-prepends the CURRENT pair at index 0 of the results whenever it isn't one of the relevance hits (PairSearchSelect.tsx:161-166)
the highlight-reset effect fires when the typed results land (deps include options.length) and parks activeIndex on selectedIndex — which is now 0, the current pair (PairSearchSelect.tsx:173-175)
Enter commits options[activeIndex] = the current pair (PairSearchSelect.tsx:229-231) -> onChange(current) -> same route -> dropdown closes back on EMBER/CORAL. Silent revert, any target pair, no error.

Proved it at the unit layer: a test that types a query whose hits exclude the current pair, waits for results, presses Enter, and asserts onChange gets the search hit — fails on main, onChange receives the CURRENT pair instead. Deterministic, not a race. Happy to hand over the repro as a regression test once the fix shape is decided.

Two things make this nastier right now:

the deploy has 26 pairs but the search list caps at 20 (PAIR_SEARCH_RESULT_LIMIT), so some pairs are only reachable by typing — which funnels users straight into this flow
the prepend is intentional for the EMPTY-query case ("keep current pair on Enter", 5e32012). The bug is that the same prepend+reset wins while a typed query is active. Fix direction: when debouncedSearch is non-empty, land the highlight on the first search hit (or skip the current-pair prepend for typed queries) so Enter commits what the user searched for.

@totdking two things to confirm from your side, since your repro steps read like a mouse-click flow (which tests green at main): did you select by clicking the option, or type + Enter? And what build is your frontend on (git rev-parse HEAD)? Heads up — the repo history got rewritten, so a plain git pull leaves a stale/diverged clone; you need git fetch && git reset --hard origin/main. If your build predates the PairSearchSelect combobox you'd literally be re-testing the old #301 control.

@PlasticDigits flagging because the type+Enter path above is a real current-main bug whichever way the original repro was hit, and this issue is tagged blocker so it gates the LR-00 sign-off.

Triaged this from source + git history + the unit layer (browser re-check is batched for my next frontend pass). Good news first: this is NOT the #301 fix regressing. TradePage.tsx hasn't been touched since the PairSearchSelect change landed, nothing in the recent wave goes near the selector files, and the #301 regression tests (the real portal-click path) are green at 83dc192. The mouse-click flow is correct at current main. But there IS a deterministic bug at current main in the type-then-Enter flow, and it produces exactly this symptom: - typing a query force-prepends the CURRENT pair at index 0 of the results whenever it isn't one of the relevance hits (PairSearchSelect.tsx:161-166) - the highlight-reset effect fires when the typed results land (deps include options.length) and parks activeIndex on selectedIndex — which is now 0, the current pair (PairSearchSelect.tsx:173-175) - Enter commits options[activeIndex] = the current pair (PairSearchSelect.tsx:229-231) -> onChange(current) -> same route -> dropdown closes back on EMBER/CORAL. Silent revert, any target pair, no error. Proved it at the unit layer: a test that types a query whose hits exclude the current pair, waits for results, presses Enter, and asserts onChange gets the search hit — fails on main, onChange receives the CURRENT pair instead. Deterministic, not a race. Happy to hand over the repro as a regression test once the fix shape is decided. Two things make this nastier right now: - the deploy has 26 pairs but the search list caps at 20 (PAIR_SEARCH_RESULT_LIMIT), so some pairs are only reachable by typing — which funnels users straight into this flow - the prepend is intentional for the EMPTY-query case ("keep current pair on Enter", 5e32012). The bug is that the same prepend+reset wins while a typed query is active. Fix direction: when debouncedSearch is non-empty, land the highlight on the first search hit (or skip the current-pair prepend for typed queries) so Enter commits what the user searched for. @totdking two things to confirm from your side, since your repro steps read like a mouse-click flow (which tests green at main): did you select by clicking the option, or type + Enter? And what build is your frontend on (git rev-parse HEAD)? Heads up — the repo history got rewritten, so a plain git pull leaves a stale/diverged clone; you need git fetch && git reset --hard origin/main. If your build predates the PairSearchSelect combobox you'd literally be re-testing the old #301 control. @PlasticDigits flagging because the type+Enter path above is a real current-main bug whichever way the original repro was hit, and this issue is tagged blocker so it gates the LR-00 sign-off.

Brouie commented

2026-06-10 02:21:10 +00:00

(Migrated from gitlab.com)

mentioned in issue #354

Brouie commented

2026-06-10 02:21:26 +00:00

(Migrated from gitlab.com)

mentioned in issue #355

Brouie commented

2026-06-10 02:22:59 +00:00

(Migrated from gitlab.com)

Refinement on my note above, from continuing the browser pass on a real client: "the mouse-click flow is correct at current main" is true of the SELECTOR logic, but click-switching still fails one layer later in a live browser — the workspace prefetch seeds a flat limit-book page into the query key the order-book panel consumes as an infinite query, and the trade view crashes to the ErrorBoundary when the panel renders. Filed with the full mechanism as #354.

Separately, the book endpoints throw real 429s under normal single-user usage because of the lcd-heavy limiter's semantics — filed as #355.

So this control currently has three distinct failure modes: the type+Enter default-revert (above), the click-switch crash (#354), and rate-limit starvation degrading the book (#355). Which one a repro hits depends on input method and limiter state — worth re-testing VP-4 only after #354/#355 land.

@totdking the build-sha + input-method questions above still stand, mostly to know which of the three you saw.

Refinement on my note above, from continuing the browser pass on a real client: "the mouse-click flow is correct at current main" is true of the SELECTOR logic, but click-switching still fails one layer later in a live browser — the workspace prefetch seeds a flat limit-book page into the query key the order-book panel consumes as an infinite query, and the trade view crashes to the ErrorBoundary when the panel renders. Filed with the full mechanism as #354. Separately, the book endpoints throw real 429s under normal single-user usage because of the lcd-heavy limiter's semantics — filed as #355. So this control currently has three distinct failure modes: the type+Enter default-revert (above), the click-switch crash (#354), and rate-limit starvation degrading the book (#355). Which one a repro hits depends on input method and limiter state — worth re-testing VP-4 only after #354/#355 land. @totdking the build-sha + input-method questions above still stand, mostly to know which of the three you saw.

Brouie commented

2026-06-10 02:31:20 +00:00

(Migrated from gitlab.com)

mentioned in issue #337

PlasticDigits commented

2026-06-10 03:34:31 +00:00

(Migrated from gitlab.com)

mentioned in commit b0f83914b1

mentioned in commit b0f83914b1241b320f222959c69b7ebca269869d

PlasticDigits commented

2026-06-10 03:34:37 +00:00

(Migrated from gitlab.com)

MR !853 on local1/350-impl-enter-commit-search-hit. Type+Enter now commits first search hit. Click-switch depends on #354; book 429s on #355.

MR !853 on `local1/350-impl-enter-commit-search-hit`. Type+Enter now commits first search hit. Click-switch depends on #354; book 429s on #355.

PlasticDigits commented

2026-06-10 03:34:37 +00:00

(Migrated from gitlab.com)

mentioned in merge request !853

PlasticDigits commented

2026-06-10 05:31:39 +00:00

(Migrated from gitlab.com)

mentioned in commit fda7cc5e37

mentioned in commit fda7cc5e37894159a97f675272356738207d5da8

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-06-10 05:31:42 +00:00

Brouie commented

2026-06-10 06:29:44 +00:00

(Migrated from gitlab.com)

Verified the merged fix (!853, commit b0f8391) at source + unit-test layer on e198dcb. The two mechanisms I flagged are both fixed in PairSearchSelect.tsx: the current-pair prepend is now gated by !debouncedSearch, and the activeIndex reset effect sets index 0 (first hit) when a query is active instead of parking on the prepended current pair. The new regression test PairSearchSelect.issue350 passes, and traced against b0f8391^ it would have failed (old code commits the current pair on type+Enter). Full PairSearchSelect suite 7/7. Browser/keyboard re-test is the laptop layer, in progress.

Verified the merged fix (!853, commit b0f8391) at source + unit-test layer on e198dcb. The two mechanisms I flagged are both fixed in PairSearchSelect.tsx: the current-pair prepend is now gated by !debouncedSearch, and the activeIndex reset effect sets index 0 (first hit) when a query is active instead of parking on the prepended current pair. The new regression test PairSearchSelect.issue350 passes, and traced against b0f8391^ it would have failed (old code commits the current pair on type+Enter). Full PairSearchSelect suite 7/7. Browser/keyboard re-test is the laptop layer, in progress.

Brouie commented

2026-06-10 06:51:02 +00:00

(Migrated from gitlab.com)

mentioned in issue #357