Repository navigation
Assert unknown per-firm fields survive a store -> save -> load cycle - #271
Conversation
/review-pr (dry run)Scope: 2 files, 1 commit at review time (now 3, after fixes below). No existing reviewer comments (fresh PR). 5 finders ran (correctness, regression, edgecases, architecture-cli, cli-conventions) — no security/error-handling signal in a test-only diff, so those two were skipped. Fixed (2 Minor, both in the test itself):
Deliberately deferred (2 Suggestions): broaden the round-trip test to cover falsy/nested unknown-field shapes, not just a truthy boolean; restructure to mirror the sibling 752/752 tests pass, lint clean. |
190c74f to
e98598f
Compare
Follow-up: a second review caught a real gap in the test itselfA second reviewer found the final assertion didn't actually depend on Fixed by: clearing the in-memory Squashed the three commits into one and force-pushed (this PR wasn't merged, no shared history to disrupt) — history now reads as a single clean commit rather than the review trail. PR body corrected to describe the actual verification. 752/752 tests pass, lint clean. |
…cycle storeNewTokenPair/saveCredentials/loadCredentials already preserve fields they don't recognize (e.g. one written by a newer CLI version) - this locks that behavior in as a regression test. Split out of a larger corruption-handling branch after a second look found the wider fix was solving a failure mode this project has specifically investigated and not found (see the parked branch/PR for the full writeup). Went through two /review-pr rounds before this shape: - the write-capture mock needed mockImplementationOnce (matches this file's own convention for a single expected call - jest.clearAllMocks() doesn't clear a registered implementation, so a persistent one would outlive this test) - the final assertion didn't actually depend on loadCredentials() doing anything: storeNewTokenPair's own in-place merge already produces the expected shape before load ever runs, so a stubbed-out no-op load still passed. Fixed by clearing the in-memory data before the load (matching what a real process restart would have) and by asserting directly on the serialized writtenData, which is what step 8 actually depends on (what lands in CONFIG_JSON) - verified non-vacuous against a broken merge, a no-op load, and a skipped write, all three confirmed red before the fix and green after.
e98598f to
4729242
Compare
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Summary
storeNewTokenPair->saveCredentials->loadCredentials.loadCredentialsassigns the parsed object directly,storeNewTokenPairmerges into the existing per-firm record rather than replacing it). This just locks it in.Why this instead of the larger corruption-handling change
This was split out of a much larger branch (see #270) that also made
loadCredentialsfail loudly on a malformed config file instead of resetting to{}. A second look at the CI auth root-cause doc found that failure mode had been specifically investigated across 36 incidents in 14 months and never observed - every incident was the revoke-on-use/concurrency class instead. The larger branch is parked, not deleted, in case that changes. This test is the one piece with a real, non-speculative driver: step 8 of the CI auth plan seeds a flag intoCONFIG_JSONand needs to know the CLI won't strip it back out.Test plan
npx jest tests/lib/api/firmCredentials.test.js- new test passesVerified non-vacuous against three independent failure modes, each confirmed red before its fix and green after: a broken merge in
storeNewTokenPair(replace instead of merge), a completely no-oploadCredentials()(the original assertion didn't actually depend on load reconstructing state - fixed by clearing in-memory data before the load and asserting on the serializedwrittenDatadirectly), and a skipped writenpm test- 752 tests, 46 suites, all passing (verified with a fresh run just before this update)npm run lint- cleanSkip bumping the CLI version