Skip to content

feat(p2): v3 usmStats Report detection and auto-resync/retry - #23

Merged
stakach merged 2 commits into
spider-gazelle:masterfrom
n-rodriguez:feat/p2-v3-resync
Jul 12, 2026
Merged

feat(p2): v3 usmStats Report detection and auto-resync/retry#23
stakach merged 2 commits into
spider-gazelle:masterfrom
n-rodriguez:feat/p2-v3-resync

Conversation

@n-rodriguez

Copy link
Copy Markdown
Contributor

Third slice of the P2 (protocol completeness) group (#7). Follows #21 (read/bulk) and #22 (write).

Problem

A v3 agent answers an out-of-sync request with a Report PDU naming a usmStats counter (notInTimeWindow, unknownEngineID, …) plus its authoritative engine params. Today that surfaces as a bare auth failure with no recovery, so a boots/time drift or an agent reboot breaks subsequent requests until the session is manually rebuilt.

Commits

  1. feat(v3): detect usmStats Report PDUs and resync engine params
    • UsmStat enum + USM_STATS_BASE, from_oid? (tolerates the .0 instance suffix), resyncable? (only notInTimeWindow / unknownEngineID).
    • Security::ReportError carrying the usm_stat.
    • V3::Message#report? / #usm_stat; V3::Session#resync_from updates engine id / boots / time from a Report.
  2. feat(client): auto-resync and retry once on a v3 Report
    • request/transceive helpers centralise the discovery probe + send/parse and the resync-and-retry-once loop. A non-recoverable Report, or one that survives the retry, raises Security::ReportError. The get/get_next/get_bulk/set send paths route through them.

Note

This composes with the RFC 3414 time-window enforcement from #20: an authenticated notInTimeWindow Report already has its boots/time absorbed by check_timeliness; resync_from additionally covers the unauthenticated unknownEngineID case, and the client drives the retry.

Tests

v3_report_spec (OID mapping, resyncable set, report?/usm_stat, resync_from) — offline. The client retry loop is socket glue, exercised by the e2e suite. Deterministic 75/75, multi-threaded 75/75, legacy 3/3, ameba clean, format clean; commits bisect-clean.

Tracked in #7. Remaining P2 slices: HC counters / ifXTable → trap/inform sending.

🤖 Generated with Claude Code

n-rodriguez and others added 2 commits July 12, 2026 01:46
A v3 agent answers an out-of-sync request with a Report PDU naming a usmStats
counter (e.g. notInTimeWindow, unknownEngineID) plus its authoritative engine
params. Model these so a manager can recover instead of surfacing an auth error.

- v3/report: USM_STATS_BASE + UsmStat enum (from_oid? / resyncable?)
- v3/security: ReportError carrying the usm_stat
- v3/message: report? / usm_stat predicates
- v3/session: resync_from updates engine id / boots / time from a Report
- spec: v3_report_spec covers OID mapping, resyncable set, detection, resync

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
On a recoverable usmStats Report (notInTimeWindow / unknownEngineID) the client
now resyncs the engine params from the report and retries the request exactly
once; a non-recoverable Report, or one that survives the retry, raises
Security::ReportError.

- client: request/transceive helpers centralise probe + send/parse + the
  resync-and-retry-once loop; the get/get_next/get_bulk/set send methods route
  through them

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@stakach
stakach merged commit 5bc3a88 into spider-gazelle:master Jul 12, 2026
6 checks passed
@n-rodriguez
n-rodriguez deleted the feat/p2-v3-resync branch July 12, 2026 01:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants