Source: #2019 at 630a6b2
Location: hypaware-core/plugins-workspace/pi/src/listener.js:83-88
Severity: minor
Evidence
Re-verified at 630a6b2 with a fresh npm install: 20 alternating rounds of a version-1 batch and an accepted version-2 batch against a live listener leave lastError undefined (batches_received 20, rejected_requests 20). state.refusals = 0 on every accepted batch (listener.js:88) resets the single shared counter, so a skewed sender interleaved with a current one never reaches SKEW_REFUSALS = 3.
Expected behavior
A Pi extension that is permanently version-skewed surfaces in capture health even when a current-version sender shares the same loopback listener.
Why deferral is safe
Safe outside this PR: the PR is strictly additive over master, which reported nothing for any skewed sender. The realistic deployment has one shared extension file (~/.pi/agent/extensions/hypaware.js, written by attachPiPlugin via piPluginPath), so every Pi process loads the same version and a mixed-version arrangement persists only while a pre-upgrade Pi process holds the old file in memory, ending at that process's restart. Fixing it requires a design choice this issue-fix PR does not own: per-sender keying adds exactly the unbounded per-session state the LLP 0416#bounds design avoids, and a sticky latch changes when the report clears; either owes its own LLP decision.
Acceptance condition
A test that interleaves version-1 and accepted version-2 batches past the threshold and asserts status() reports the skew; it fails on the current head and passes after the chosen design (per-sender window or sticky latch) lands with its LLP.
Evidenced behavioral defect; eligible for automatic repair.
Source: #2019 at 630a6b2
Location: hypaware-core/plugins-workspace/pi/src/listener.js:83-88
Severity: minor
Evidence
Re-verified at 630a6b2 with a fresh npm install: 20 alternating rounds of a version-1 batch and an accepted version-2 batch against a live listener leave lastError undefined (batches_received 20, rejected_requests 20). state.refusals = 0 on every accepted batch (listener.js:88) resets the single shared counter, so a skewed sender interleaved with a current one never reaches SKEW_REFUSALS = 3.
Expected behavior
A Pi extension that is permanently version-skewed surfaces in capture health even when a current-version sender shares the same loopback listener.
Why deferral is safe
Safe outside this PR: the PR is strictly additive over master, which reported nothing for any skewed sender. The realistic deployment has one shared extension file (~/.pi/agent/extensions/hypaware.js, written by attachPiPlugin via piPluginPath), so every Pi process loads the same version and a mixed-version arrangement persists only while a pre-upgrade Pi process holds the old file in memory, ending at that process's restart. Fixing it requires a design choice this issue-fix PR does not own: per-sender keying adds exactly the unbounded per-session state the LLP 0416#bounds design avoids, and a sticky latch changes when the report clears; either owes its own LLP decision.
Acceptance condition
A test that interleaves version-1 and accepted version-2 batches past the threshold and asserts status() reports the skew; it fails on the current head and passes after the chosen design (per-sender window or sticky latch) lands with its LLP.
Evidenced behavioral defect; eligible for automatic repair.