fix(wallet,ui): keep one implementation of the transaction column filter - #232
Merged
Merged
Conversation
The transactions table filtered its columns twice: `txFilterParams()` sends the typed value to the server (`tx_where` -> `model LIKE ?`, a trimmed parameter), and `buildDataTable` then re-filtered the very rows the server had already filtered, locally, with `filterRows(list, TX_COLUMNS, txTable.filters)`. The two implementations do not agree, so rows the server accepted could be dropped by the local pass: * text columns: the wire `trim()`s the value, the local predicate compares the raw string - typing `"deepseek "` (trailing space) matches on the server and then disappears from the table; * the LIKE wildcard: typing `%` returns every row from the server, while the local literal comparison keeps none (measured: server=5, table=0, count=5); * `exportTxCsv` re-ran that same local filter, so the CSV exported 0 rows for a filter the server had satisfied. Fix - one implementation: every `TX_COLUMNS` column that carries a `filter` declares `serverFilter: true` (6 columns) and `filterRows` skips those columns. That makes the duplicated pass a no-op at all three of its consumers (`renderTxSummary`, the table row count, `exportTxCsv`) without touching the server contract. The invariant is written next to the declarations and in `ui/README.md`, so a new filterable column must declare it or the second implementation returns. The server side's rule - which the front end now relies on alone - is pinned by a new Rust test (`tx_text_column_filters_trim_the_value_before_matching`): a trailing space is equivalent to no space, a blank value means "do not filter", and `%` is a LIKE wildcard, with a negative control so that a degenerate "never filter" cannot pass.
argszero
added a commit
that referenced
this pull request
Sep 22, 2026
) The transactions table's column headers carry a sort arrow, and that arrow is a claim about the WHOLE dataset: the pager below it counts the backend's `total` (30 rows, "1 2 3 / 3 · 30 rows") and the summary card above it is a backend aggregate. The ordering, however, only ever applied to the page in hand. `#135` turned the list into a server-paged table (`serverPaging` = backend total, one page of rows per request, `LIMIT/OFFSET` over `ORDER BY t.id DESC`), while sorting stayed where it was born in the static prototype (`#7`, `d70e032`): client-side, over whatever rows the caller passed in -- if (state.sort.length) { data = data.slice().sort(...) } const pageRows = serverPaging ? data : data.slice(...) a page. So clicking "Points" ▲ reordered the ten rows on screen and painted ▲, while the row that actually holds the minimum sat on page 2/3 and was never fetched; the request never changed. The column FILTERS travelled the other half of that road long ago (`#232` `e7bfc6f` / C2114: "local filter of the current page" -> "backend full-dataset filter"); the sort half never did. Fix: one claim, three carriers, and a server that renders `ORDER BY` from a whitelist. * `ui/js/app.js` — `txSortParams()` projects the single sort state (`txTable.sort`) into the LIST request only (the trend endpoint buckets by time; row order means nothing to it). `txQuerySig()` now covers the sort, so the reload guard refetches when a header is clicked -- without that line the arrow would move over a list that does not, which is worse than the defect being fixed. The local sort steps aside when the call site declares `serverSort`: `if (state.sort.length && !(serverPaging && serverSort))`. * `src/routes/wallet.rs` — `TX_SORT_KEYS` (11 keys, exactly the sortable columns of `TX_COLUMNS`) + `tx_sort_expr()` + `tx_order_by()`. The user string never reaches SQL; the `ORDER BY` fragment is rendered from the whitelist, always with a trailing `, t.id DESC` (a non-unique sort makes `LIMIT/OFFSET` page boundaries indeterminate -- one row twice, another never), and an unknown key / mismatched key-direction count / bad direction is a 400. Validation runs before the DB lock, as `type` does. Expressions match what the cell shows (`pts` via `signed_pts_expr`, the four token columns on their raw values, `model`/`key` byte-identical to the filter expressions). Tests: * `state_gate::the_sort_indicator_and_the_order_by_share_one_source` — four rules, each with its own mutant leg, plus a `the_r164_rules_have_teeth` self-proof over self-contained mini sources and a `the_r164_roster_is_real` positive control. Roster == whitelist == match arms, `q.sort`/`q.dir` bound in exactly one place, the guard reads the WHOLE condition (a `[^)]*` reader cannot see `!(a && b)`) and a control rule keeps the filter half of the same road honest. * `src/routes/wallet.rs` — three behaviour tests: the whole set is ordered (not the page), ties are stable across pages, and anything outside the whitelist is rejected. * jsdom probe (7 legs, both directions): on the pre-fix tree the two global-extremum legs and the "did the request carry sort" leg fail; on the landed bytes all seven pass. The two competing "fixes" (keep sorting the page and caption the arrow " (this page)"; stop painting the arrow) are rejected by the same legs. Scope, stated honestly: the gate is lexical -- it proves the three carriers agree and that the whitelist IS the column roster; it does not prove that the rows on screen are globally ordered (that is the jsdom probe's job, and there is no JS runner in `cargo test`), nor the `ORDER BY` semantics themselves (those are the wallet behaviour tests). Recorded in `ui/README.md`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The transactions table filtered its columns twice:
txFilterParams()sends what the user typed to the server (tx_where->model LIKE ?, with the parameter trimmed on the way out), andbuildDataTablethen re-filtered the very rows the server had already filtered, locally, withfilterRows(list, TX_COLUMNS, txTable.filters).The two implementations do not agree, and the local one wins, so a filter the server satisfied can end up showing nothing:
deepseekdeepseek(trailing space)qwen(leading space)%LIKE '%'matches everything)%)The same duplicated pass also ran inside the CSV export, so
导出 CSVproduced a file with 0 data rows while the server had returned 5 for the filter in force.Related Issue
Not applicable - self-discovered defect, no issue exists in the tracker (none fabricated).
Changes
ui/js/app.js: everyTX_COLUMNScolumn that carries afilternow declaresserverFilter: true(6 columns: type / user / model / key / pts / status), andfilterRowsskips those columns. That single change makes the duplicated pass a no-op at all three of its consumers -renderTxSummary, the table row count andexportTxCsv- so the rows the server returned are the rows on screen and in the file.TX_COLUMNS,filterRows) and inui/README.md, so a new filterable column must declareserverFilteror the local second implementation comes back.ui/index.html:app.js?v=20260914-8->-9(cache bust).src/routes/wallet.rs: a new test pins the server-side rule the front end now relies on alone -tx_text_column_filters_trim_the_value_before_matching.No ledger, balance or settlement code is touched - this is the display / filter surface only.
Tests
cargo test- 239 passed, 0 failed (was 238; the new test is the+1).cargo fmt --check- clean.cargo clippy --all-targets -- -D warnings- clean.tx_text_column_filters_trim_the_value_before_matchingasserts that a trailing space is equivalent to no space, that a blank value means "do not filter" (3 rows, not 0), that%behaves as a LIKE wildcard (3 rows), and carries a negative control (model=zzz-> 0 rows) so that a degenerate "never filter" implementation cannot pass.Front-end instrument (jsdom, real
ui/index.html+ the four real scripts; onlyfetchand the download are stubbed)15 checks:A0built-in control (every fixture row renders),P0a control on the wire rule itself,A1the plain path (control),B1-B4the axis (padded value / leading space / blank / LIKE wildcard),C1the wire carries the trimmed value,E1a genuinely non-matching value still yields 0 rows,D1the exported CSV contains the rows the server returned for the filter in force.ui/js/app.jsv0_orig(pre-fix,dfa7318)58ce4a47ba5092e507b6659cbeb1461f{B1a B1b B2a B2b B3a B3b B4a B4b D1}m_trim(keep the duplicate, trim its value - the plausible half fix)879407d8d3a7e693df4223680dd43188{B4a B4b}m_notrim(delete the wire normalisation instead - the wrong direction)bba9d6c505deb29688287115c88f131e{B1a B1b B2a B2b B3a B3b B4a B4b C1 D1 P0}live(this tree)9f606a23367f95bf243662a474a8fe56{}The pre-change tree is rejected with exactly the frozen red set;
m_trimshows that normalising the duplicate fixes the whitespace face but not the wildcard face (so "make the copies agree" is not the fix);m_notrimshows the mirror-image repair is rejected too, and it also trips the wire-rule control (C1/P0) - i.e. the instrument pins the correct direction, not merely "behaviour changed". Recorded honestly:m_trim ⊂ v0_orig, andm_notrim's red set strictly contains the baseline's.Checklist
fix/tx-column-filter-single-implementation.+79/-11, no config / schema / i18n key change, no new dependency.