fix(strr-examiner-web): ignore stale invoice responses - #1819
Draft
Jacky-Pham wants to merge 1 commit into
Draft
Jacky-Pham wants to merge 1 commit into
Jacky-Pham wants to merge 1 commit into
Conversation
|
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.
A slow invoice response can replace the amount and payment date shown for a newer application. The old response can also restore metadata after a record-load failure or after switching to a registration, snapshot or application without an invoice. A record change that keeps the same invoice ID can leave previously displayed metadata behind.
Give payment lookups a request sequence and watch the selected record, invoice ID and payment account. Every change clears the display metadata and invalidates older lookups; only the latest successful invoice response can populate the amount/date. Existing invoice-error logging, zero-total display and unavailable-data fallback are preserved.
Validation: 14 new cases use the real store, record loaders and ApplicationInfoHeader with synthetic API responses. Eight fail on the parent source; all pass after the repair. All 95 targeted tests pass, and lint reports only two existing line-length warnings. All 333 Examiner unit tests pass locally. Paired strict checking retains the same 140 existing diagnostics, with none introduced. Standalone CI passes lint, all 333 tests and build. Combined CI passes all five frontend lint/test/build jobs with 908 tests, including 350 Examiner tests. Combined strict checks retain 364 existing diagnostics, with none introduced.
Stacked on #1818. This covers payment display state; authenticated Examiner browser verification remains outstanding.