[woahwhattheheck]

Closes #278

Summary

Transfer history uses a filter-scoped snapshot so concurrent inserts cannot duplicate or omit rows while paging. This continuation fixes recovery and selection behavior, prepares sort keys once, and repairs existing CI fixtures.

Behavior and compatibility

• Freeze filtered membership in descending creation-time order with locale-aware ID ties and stable equal-key order. Keep every matching row, with five rows per page; no result cap or cache is introduced.
• Bind cursors to the snapshot generation, filter scope and prior row key. Expired, malformed or out-of-scope cursors recover to a fresh first page. Snapshots expire after five minutes; filter changes reset them, and empty snapshots rebuild when loading supplies rows.
• Mint distinct in-memory generation IDs even when replacement snapshots share a clock tick, filter and row count. An old cursor cannot alias that replacement.
• Refresh existing members' live fields without reshuffling membership, including when their fields cease matching the filter. Retain captured records for vanished rows; new inserts appear in the next snapshot.
• Clear explicit selections and select-all when filters change or a persisted snapshot generation is replaced. Preserve selection during same-generation refresh. URL filters and pagination controls remain compatible.
• Keep the maintained review/confirmation/result/receipt flow and canonical decimal assertions. Offline blocking, retry, exactly-once creation and money checks remain. A valid amount that cannot be priced now receives the pricing explanation.

Snapshot performance

The sorter prepares timestamp/string-ID keys once per populated row and returns the original row references. It preserves locale ties, invalid-date fallback and undefined/sparse placement.

Measured calls to the actual snapshot constructor include record copying: Node 22.16.0, two warmups and five alternating paired samples per workload, with complete output equality:

• 5,000 shuffled: 20.349 → 3.071 ms (6.63x).
• 100,000 shuffled: 620.098 → 80.338 ms (7.72x).
• 100,000 oldest-first: 37.541 → 28.876 ms (1.30x).

Separate untimed counting measured 3,058,470 → 100,000 timestamp parses for the large shuffled case. The tradeoff is one temporary key record per populated row; peak memory was not measured. Storage parsing, network/provider work and React rendering are excluded.

Benchmark, raw samples, exact source pins and focused execution.

Validation and current status

Current head: 1ee074a. Subsequent lookup, across-page selection, and inactive-date-filter changes retain their source-specific evidence below.

• Earlier full selection: source 157ff7b passed 477 tests across 49 files, with zero failed/pending/todo/skipped. Node 24.19.0 / Vitest 4.1.10; 56.57 s reported, 57.113 s process. Existing formatting and production build passed (1.55 s Vite). All 344 tracked files stayed unchanged after execution.
• Later sorter validation: source 2ae9335 passed 13 focused tests, zero failed/skipped, in 1.53 s; changed JavaScript passed Prettier and the production build passed (917 ms Vite), on Node 22.23.3. Those tested sorter bytes are retained in the current head. The earlier 477-test aggregate was not rerun or relabeled as a current whole-suite result.
• Dated critical audit: the 4 October 2026, 11:56 UTC receipt exited 0 with 0 critical / 20 high / 12 moderate / 2 low. It is reused for identical package/lock bytes; remaining findings are not claimed repaired.

Aggregate commands, receipt and raw evidence. Hosted CI and Lighthouse require approval; maintainer acceptance remains pending.

Page lookup continuations

At 3bb8747d, page lookups retain only visible snapshot IDs rather than allocating a full-history Map and temporary pairs for each page. The lookup preserves the last duplicate-ID winner, exact live references and captured-record fallback for missing rows, with no persistent cache. Direct production-module measurement on Node 22.16/Linux: 100,000 rows with the default five-row page measured 14.269 → 1.606 ms median (8.89x); lookup cardinality fell from 100,000 to 5. Complete outputs and references matched across bounded mutation, insertion, duplicate, expiry and scope observations. Source pins, all four workloads, raw samples and runnable measurement.

Subsequent source afa3b0ef retains the bounded page map and avoids unnecessary live-history traversal. Ordinary arrays are scanned backward so the first match preserves the last-duplicate-wins policy; scanning stops after every visible ID is resolved. Empty pages read no live records. Missing IDs retain their snapshot fallback after a full scan. Sets, generators and custom array iterators keep their forward-only behavior.

Three focused assertion groups passed against the complete production module, and all six benchmark workload outputs and record references matched the preceding source. On Node 22.16, the 100,000-row ascending-input newest page measured 2.793942 → 0.007302 ms, and an empty filtered snapshot 1.590464 → 0.002271 ms. Full-scan controls were essentially unchanged: descending first page 2.754172 → 2.726743 ms; ascending last page 2.798958 → 2.804947 ms. Nine alternating pairs, twenty calls per sample. Source pins, reproduction program, raw samples and limits.

These results depend on input position and measure only the helper. Prior benchmark ratios must not be multiplied; no browser, provider or whole-application speedup is claimed. No Vitest suite, build or workflow was rerun for either lookup continuation; earlier validation remains source-specific. Maintainer acceptance remains pending.

Across-page deselection

Across-page deselection now converts the frozen membership to explicit IDs before removing a row or page, so other-page selections survive. The maintained selection integration file passes all five cases with no skipped cases on Node 24.21.0 and unchanged locked dependencies at production source 6ed4086f; both new cases fail against the preceding component. Scoped formatting and source-identity checks pass. Execution and limits.

Inactive date filter

At production source 9f1debe8, the All time filter defers its default Date allocation until a nonzero date range needs it. Supplied clocks, inclusive cutoffs, invalid dates and active ranges keep their behavior. Previous selection and pagination changes remain.

A native Node 22.16.0/Linux measurement of Array.filter calling the complete production helper over 100,000 records used three warmups and nine alternating paired samples. The All time median measured 12.115259 → 4.508355 ms (62.79% less time), with identical membership, order and object references; separate untimed clock allocations fell from 100,000 to zero. The active 30-day control measured 62.660949 → 60.724011 ms with 100,000 allocations in both implementations; that small difference is not treated as a material active-filter gain. Rendering, API and storage work are excluded.

Native run 37206173166 passes all eight unchanged transfers-filter integration cases at pinned source 9f1debe, including no-filter display, date presets and URL restoration. The original lock is installed; scoped formatting and clean-worktree checks pass. No test file or dependency was added. Source pins, raw samples, reproduction and limits.

These separate source-bound results are not combined into a current-head whole-suite total or a cumulative performance multiplier. No full build, deployed throughput, acceptance or payout is asserted for these continuations.