test: make privacy capture independent of callsite order #7
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/privacy-log-capture-20261029"
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?
The privacy tests could miss a warning when a parallel non-capturing thread first registered its tracing callsite. The error response was correct, but the positive log assertion failed intermittently. This carried fork test-infrastructure patch replaces per-test subscribers with one stable subscriber and separate thread-local sinks; production logging and all API/auth/token code stay unchanged.
A fresh-process regression deterministically fails the old capture helper and requires exactly one child test to run. Additional coverage checks parallel isolation and nested restoration. Existing positive log-count and private-value assertions remain unchanged. Two independent reviews completed; the final exact head
007ed1baceis approved for source merge after CI. Local format, Clippy,119 tests, audit and deny pass. The dated pitfall records the cause and avoids treating an empty capture as privacy proof.Residual: a very narrow first-subscriber-publication/in-flight callsite-registration race in tracing-core can still cause a safe test failure; rebuilding interest on each capture narrows it, and positive assertions prevent false privacy passes. The deterministic regression covers the observed cross-thread first-use defect, not that internal library transition.
This is not a release promotion. Separate qualification found6 dependency advisory entries in the unchanged lockfile; their dependency/runtime remediation and final artifact/authenticated-client gates remain mandatory before release or deployment. No real service calls or measurements were used by these tests.