feat: per-partition cookie jar via requester.perPartitionCookieJar - #1549
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1549 +/- ##
===========================================
+ Coverage 75.16% 75.91% +0.75%
===========================================
Files 50 50
Lines 3946 3974 +28
Branches 1137 1151 +14
===========================================
+ Hits 2966 3017 +51
+ Misses 734 721 -13
+ Partials 246 236 -10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2dbc1f6 to
30667d7
Compare
shamasis
left a comment
shamasis
left a comment
There was a problem hiding this comment.
LGTM. The general direction looks okay. I checked to see what is the verdict on memory impact and what has been the teardown strategy for these cookiejars.
The response was. @scriptonist maybe this is of interest.
In default chunked parallel mode (maxConcurrency > 1), a partition runs a contiguous block of N iterations (cyclesPerPartition) and the jar persists across all of them — it's never reset (reset only happens in customParallelIterations recycling). So the unit of isolation is "parallel worker," which equals one iteration only in customParallelIterations mode.
The CHANGELOG's "isolated cookie jar per partition (per-VU)" is misleading for chunked mode, and "VU" (virtual user) is a load-testing term that appears nowhere else in runtime. Recommend describing it precisely (e.g., "per parallel partition; equals per-iteration in customParallelIterations mode").
|
Later, if we genuinely wants per-iteration isolation (fresh jar every iteration even within a worker — i.e. treat each iteration as a stateless request), that's a distinct feature with the opposite tradeoff, and it should be its own explicitly-named option rather than overloading this one. I wouldn't fold it in here; I'd just make sure the docs don't imply this flag does it. |
…ieJar) One RequestCookieJar() per runner.run() (requester-pool.js) means every partition (VU) shares a single Set-Cookie store: session/auth cookies cross-contaminate at the wire even though every pm.* variable scope is per-partition isolated. Root-cause analysis and empirical repro in perftest's agent/variable-scoping-findings.md. Fix: opt-in requester.perPartitionCookieJar gives each partition its own lazily-allocated jar. - partition.js: lazy getCookieJar()/resetCookieJar(); fresh VUs are born with empty jars (not cloned from run state, unlike variables) - run.js: Run#getCookieJarFor(coords) is the single resolution point; coords.partitionIndex reaches httprequest on every path (items, pm.sendRequest via cloned script cursor, auth replays via createItemContext). Explicit requester.cookieJar always wins (warn). - requester-pool.js: per-trace jar override via merged options copy; jar reference frozen at requester creation (late writes from a recycled VU land in the dead jar, not the fresh one) - event.command.js: execution.cookies bridge captures the jar at listener registration for the same late-write safety; pm.cookies and pm.cookies.jar() become partition-scoped with no sandbox changes - partition-manager.js: stopSinglePartition resets the jar when a recycled partition index is reused (customParallelIterations mode) Default off: Newman/desktop/waterfall behavior unchanged (pinned by an integration test against a local cookie server).
dd710fb to
3e55d48
Compare
VU (virtual user) is a load-testing term that appears nowhere else in runtime. Sweep it from comments, test titles, and fixtures; reword the CHANGELOG entry to state the isolation unit precisely (per parallel partition; equals per-iteration in customParallelIterations mode). Addresses review feedback on #1549.
Addresses review feedback on #1549.
…sole trigger The 'ignored because cookieJar is set' warning used a raw console.warn in the Run constructor, so it went to stdout and never reached consumers that surface runtime messages via the console trigger. Record the intent at construction and emit it via triggers.console in Run#start, once triggers exist. Also correct the partition cookie-jar comment: the jar is allocated on a partition's first request/script (first getCookieJarFor resolution), not on run start and not gated on actual cookie traffic. Addresses review feedback on #1549.
Let the release tooling (shipit/yankee) assign the version and date instead of hardcoding 7.55.0 and a premature date.
3 participants
Summary
Adds opt-in
requester.perPartitionCookieJarsupport so each parallel partition/VU can use its own HTTP cookie jar instead of sharing the runner-level jar.Changes
pm.sendRequest, auth replays, andpm.cookies.jar()through the partition jar when enabled.requester.cookieJarstill takes precedence.Validation
npm run test-lintnpm run test-unit