Found while verifying the child-reporters RFC (#398). Affects @svta/cml-cmcd 2.5.0, event mode. Follow-up to the disposal cleanup in #360.
Summary
CTA-5004-B scopes HTTP 410 suppression to the session: on 410 the client must cease reporting to that endpoint "for the remainder of the current session". CmcdReporter.disposeEventTarget() deletes the target from the eventTargets map permanently, so the suppression outlives the session, and the async response handling has no session guard, so a 410 from an old session can kill the new session's target.
Reproduction
Disposal survives a session change:
const reporter = new CmcdReporter({ sid: 's1', eventTargets: [target] }, requesterReturning410)
reporter.recordEvent('e') // requester called once, responds 410, target disposed
reporter.update({ sid: 's2' }) // new session
reporter.recordEvent('e') // requester never called again — target map is empty
One requester call total; the new session reports nothing.
Delayed 410 crosses the session boundary:
A report sent during session s1 whose 410 response resolves after update({ sid: 's2' }) disposes the target inside session s2, which the spec does not permit (the 410 belongs to s1).
Proposed fix
- Restore disposed targets on session reset (
sid change re-arms every configured target).
- Guard the async 410 handling with a session epoch so a response from a previous session cannot dispose a current-session target.
Found while verifying the child-reporters RFC (#398). Affects
@svta/cml-cmcd2.5.0, event mode. Follow-up to the disposal cleanup in #360.Summary
CTA-5004-B scopes HTTP 410 suppression to the session: on 410 the client must cease reporting to that endpoint "for the remainder of the current session".
CmcdReporter.disposeEventTarget()deletes the target from theeventTargetsmap permanently, so the suppression outlives the session, and the async response handling has no session guard, so a 410 from an old session can kill the new session's target.Reproduction
Disposal survives a session change:
One requester call total; the new session reports nothing.
Delayed 410 crosses the session boundary:
A report sent during session
s1whose 410 response resolves afterupdate({ sid: 's2' })disposes the target inside sessions2, which the spec does not permit (the 410 belongs tos1).Proposed fix
sidchange re-arms every configured target).