Repository navigation
Per-test trace slicing and tracePolicy for the Python adapter #361
Description
Part of #330.
A Python trace mode run writes one archive, always, whatever the outcome.
traceGranularity, tracePolicy, per-test screenshot/video and Allure
attachment all have no Python equivalent, and the first of those is what the
other three depend on.
That is a real gap rather than a structural impossibility: the backend already
holds every input it would need.
What already exists
| Need | Where it is |
|---|---|
| The retention decision | core/trace-retention.ts shouldRetainTrace(policy, {outcomes, attemptInfoAvailable}) — imports only @wdio/devtools-shared, no driver, no framework |
| Per-test outcome | backend/src/baseline/types.ts TimeWindowNode.state |
| Per-test window | the same node's start / end |
| The streams to slice | ActiveRun.commands, consoleLogs, networkRequests, mutations, actionSnapshots, screencastFrames — all timestamped |
The pytest plugin already feeds those nodes; Preserve & Rerun needed them. No
new capture is required.
What is missing
- Move
trace-retention.tsfromcoretotrace. A pure file move — it
already satisfies thetracerule (sharedand nothing else). Today
backendhas zero dependency oncoreby design (§2.2), so this is what
makes the policy reachable at all. Worth doing on its own merits: retention
living incoreis a layering smell now that a non-core consumer wants it. traceGranularityandtracePolicyonTraceExportRequest
(shared/src/trace-export.ts), so the adapter can state what it wants.- Slice-by-window in the backend. The real work.
core/spec-trace-helpers.ts
cannot move — it pulls innode:path,./uid.js,./artifact-naming.jsand
is built around aTraceCapturerthe backend does not have. Mechanically this
is "filter six arrays by[start, end]per test node"; the risk is in the
edges — a command straddling a boundary, a mutation anchored before its test
began, screencast frames shared across neighbouring tests.
Known limitation from day one
retain-on-first-failure needs per-attempt outcomes. pytest reruns
(pytest-rerunfailures) are not tracked by the plugin's registry, so
attemptInfoAvailable would be false and shouldRetainTrace would degrade to
retain-on-failure — which it already handles explicitly (degradedToFailure),
the same way Nightwatch's BDD interface does. Graceful, but the support would
carry an asterisk unless attempt tracking is added too.
Acceptance criteria
A Python run with traceGranularity: 'test' writes one archive per test, and
tracePolicy: 'retain-on-failure' keeps only the failing ones. The retention
decision is made by the same shouldRetainTrace the JS adapters use, not a
second implementation. retain-on-first-failure degrades to retain-on-failure
with the existing warning until attempt tracking exists.
Sequencing
After #294. Publishing without tracePolicy is honest as long as #358 says
so, and adding it later is additive. Doing it first delays a release already
gated on three other decisions.
Size: M (step 1 is S; step 3 carries the risk).
Activity