📌 Description
SettlementsPanel's open() (src/components/SettlementsPanel.tsx) calls run(), which on success calls reload(). reload() sets state back to { status: "loading" } and re-triggers the mount effect, which always fetches { page: 1, pageSize, ... } — page 1 only. If a user has clicked "Load more" one or more times (accumulating settlements from pages 2, 3, etc. into state.settlements via loadMore()), then successfully opens a new settlement, open()'s reload() discards all of that accumulated pagination progress: the table drops back to a bare TableSkeleton, then re-renders with only page 1's rows once the fetch completes, silently losing every row the user had loaded beyond the first page. runSettlementAction (used for Execute/Cancel) does not have this problem — it patches the specific settlement in place via settlements.map(...) without touching pagination.
🧩 Requirements and context
- Opening a new settlement should not discard already-loaded "Load more" pages or flash the table back to a loading skeleton.
- The newly-opened settlement should still end up visible to the user in a reasonable way (e.g. prepended to the currently-loaded list, or surfaced via the existing toast) without requiring a full page-1 refetch.
runSettlementAction's existing in-place-patch behavior for Execute/Cancel is the precedent to follow and must remain unaffected.
🛠️ Suggested execution
- Update
open() in src/components/SettlementsPanel.tsx to avoid calling the full reload(); instead, on a successful openSettlement(input), merge the returned settlement into the existing state.settlements (e.g. prepend it) the same way runSettlementAction merges an updated settlement, preserving all currently-loaded pages.
- Extend
src/components/SettlementsPanel.test.tsx with a test that loads a second page via "Load more", then successfully opens a new settlement, and asserts the previously-loaded second-page rows are still present in the table afterward (not reset to only page 1).
✅ Acceptance criteria
🔒 Security notes
No new attack surface; a client-side state-management fix preventing an accidental loss of already-fetched, already-authorized data from view.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
SettlementsPanel'sopen()(src/components/SettlementsPanel.tsx) callsrun(), which on success callsreload().reload()setsstateback to{ status: "loading" }and re-triggers the mount effect, which always fetches{ page: 1, pageSize, ... }— page 1 only. If a user has clicked "Load more" one or more times (accumulating settlements from pages 2, 3, etc. intostate.settlementsvialoadMore()), then successfully opens a new settlement,open()'sreload()discards all of that accumulated pagination progress: the table drops back to a bareTableSkeleton, then re-renders with only page 1's rows once the fetch completes, silently losing every row the user had loaded beyond the first page.runSettlementAction(used for Execute/Cancel) does not have this problem — it patches the specific settlement in place viasettlements.map(...)without touching pagination.🧩 Requirements and context
runSettlementAction's existing in-place-patch behavior for Execute/Cancel is the precedent to follow and must remain unaffected.🛠️ Suggested execution
open()insrc/components/SettlementsPanel.tsxto avoid calling the fullreload(); instead, on a successfulopenSettlement(input), merge the returned settlement into the existingstate.settlements(e.g. prepend it) the same wayrunSettlementActionmerges an updated settlement, preserving all currently-loaded pages.src/components/SettlementsPanel.test.tsxwith a test that loads a second page via "Load more", then successfully opens a new settlement, and asserts the previously-loaded second-page rows are still present in the table afterward (not reset to only page 1).✅ Acceptance criteria
🔒 Security notes
No new attack surface; a client-side state-management fix preventing an accidental loss of already-fetched, already-authorized data from view.
📋 Guidelines