fix(storefront): consume the expected_status override per request - #56
Merged
Conversation
pm.variables lives for the whole run, not one request — so after Capture Stripe checkout without payment set expected_status=402 (and correctly passed), every later request in the run was asserted against [402] and ten healthy 200/201 responses were reported as failures, e.g.: Before Cash Pickup Checkout responds 2xx got HTTP 200: expected 200 to be one of [ 402 ] Unset the variable in the collection baseline immediately after reading it, so an override applies to exactly the request whose beforeRequest script set it. Safe: the collection-level script runs before the request-level afterResponse, which only inspects pm.response, and the error-payload skip uses the already-captured const. Validation: node scripts/validate-collections.js (5 collections, 3 environments); postman collection lint on Fleetbase Storefront API — 62 items, 0 errors, 0 warnings.
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.
What happened
Follow-up bugfix to #55. The re-run of the storefront contract job shows the original 10 failures are gone — customer updates authenticate, the 402 negative contract asserts correctly, and the cash capture creates a real order — but 10 NEW failures appeared, all shaped like:
Every one is a healthy 2xx being held against
[402]. Root cause:pm.variablesis run-scoped, not request-scoped. OnceCapture Stripe checkout without paymentsetexpected_status = 402in its beforeRequest script, the variable stayed set, and the baseline assertion applied the 402 expectation to every request that ran after it.Fix
One line in the collection baseline script:
pm.variables.unset('expected_status')immediately after reading it, so an override applies to exactly the request whose beforeRequest script set it. A comment documents the run-scope gotcha for the next person.Safe because the collection-level afterResponse runs before the request-level one (which only inspects
pm.response), and the error-payload skip uses the already-captured const.Validation
node scripts/validate-collections.js— 5 collections, 3 environments validatedpostman collection linton Fleetbase Storefront API — 62 items, 0 errors, 0 warningsAfter merge, re-running the storefront#91 contract job should be fully green — no companion changes needed this time (fleetbase/fleetbase#635 is already merged and its sequence is correct).