test: an empty-array POST body escapes the e2e unstubbed-request guard #187
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up from the fourth review of
#185, raised as non-blocking there and
filed rather than dropped.
Problem
In
tests/e2e/network.js, the guard that reports unrecognised POST bodies usesbatch.every(...). On an empty array that predicate is vacuously true, so aPOST with body
[]is fulfilled with200 []instead of being reported as anunstubbed request. Verified by execution during review - the run stayed green.
This is a hole in the one mechanism whose entire job is to ensure unrecognised
outbound traffic fails the suite rather than passing silently. It is unreachable
in practice today, which is why it did not block the PR, but "unreachable today"
is exactly the qualifier that stops being true later.
Also in scope: a comment that overstates the guard's rationale
tests/e2e/network.js:137-140claimspostData()returnsnullforundecodable bodies. That is not quite right.
playwright-core@1.56.0(lib/client/network.js:89) doesbuffer.toString("utf-8") || null, so a binary body is lossily decodedrather than yielding
null; only an empty decode producesnull. The guard iscorrect and load-bearing either way - both paths end up reported - but the
stated reason is wrong, and the PR author independently disclosed that they
could not reproduce the
sendBeacon/Blob case the comment implies.Correct the comment to describe the two real paths: an empty or absent body
decodes to
nulland hits the type guard; a binary body decodes lossily toinvalid JSON and hits the
catch.Definition of done
[]is reported as an unstubbed request and fails the suite.before and red after. A fix asserted but not demonstrated does not count.
JSON body,
[null]batch. These were verified working during review and mustnot regress.
tests/e2e/network.js:137-140states the actual mechanism.Note
Keep this small. Do not redesign the guard, and do not touch
TRAILING_WATCH_MSor the canary - both were deliberately ruled out of scope during review and are
documented as they stand.
Done in #267 (branch
test/issue-187-empty-batch-guard, basenext).batch.length === 0added to the guard; comment corrected to the two real paths. Nothing else touched —TRAILING_WATCH_MSand the canary left as they stand,ALLOWED_ERRORSstill[].Verified by execution with a throwaway four-POST probe, added for the two runs and removed before the commit:
# probe [] -> fulfilled,ok 28 - PROBE empty-array batch []— green, the hole# probe [] -> rejected: Failed to fetch,not ok 28withnetwork: unstubbed request: POST https://e2e-probe.invalid/rpc— redSiblings reported and failed in both runs: bodyless POST, scalar JSON body,
[null]batch. Tests 1-27 stayed green throughout, so the widened ConfirmTx RPC fixtures are not misreported. Full captures are in the PR body.make checkgreen (576 tests,test-verify-build18 cases, prettier clean);make test-e2egreen at 27/27 with the probe removed.