ilpanich / axiam-typescript-sdk / 31902019387

94%

push

github

feat(reactor): ship the CONTRACT.md §22 reactor runtime (R2.5) (#60)

A **Reactor** is an external process that subscribes to named hook events on
the AMQP bus and answers back — allow, deny, or a field-allow-listed mutation
— inside a timeout the server declared. This adds `src/amqp/reactor/`,
`reactorServe(config, handler)` (the name §22.10's per-language table gives
this runtime in TypeScript), a runnable `examples/reactor/`, and the §22.13
conformance tests.

## The rule this does not paper over

A reply is an instruction to change a token or refuse a login, so an unsigned
reply is not a weak reply — it is not a reply at all. §8's HMAC now runs in
**both** directions on one exchange, with the same tenant subkey: the server
signs the event, the reactor signs the reply. Every event is verified
(`key_version >= 2`, MAC, ±300 s freshness in both directions, nonce seen-set)
*before* user code sees it, and every reply is signed before it leaves.

## Two canonicalization quirks, both silent failures

The first is shared with every SDK: a reactor body signs `hmac_signature` as
**`null`**, where `AuthzRequest` and `AuditEventMessage` omit it entirely.

The second is TypeScript's alone. `Date.prototype.toISOString()` always emits
three fractional digits; the server's `chrono::DateTime<Utc>` emits none when
the nanoseconds are zero. A reply timestamped `…T12:00:00.000Z` is
re-serialized server-side as `…T12:00:00Z`, over different bytes than the
reactor signed, and the signature fails with no other symptom.
`toChronoRfc3339()` is the fix; the runtime always uses it and a test pins both
branches.

Neither is asserted from prose. `testdata/reactor_v2_reference_vectors.json` is
the server-generated §22.13 fixture, vendored beside the §8 vectors it shares a
master key, tenant and derived subkey with — one loader serves both, and the
suite reproduces every committed `canonical_signed_json` byte-for-byte and
recomputes every `hmac_signature_hex`, including the omi... (continued)

1146 of 1242 branches covered (92.27%)

Branch coverage included in aggregate %.

172 of 172 new or added lines in 3 files covered. (100.0%)

1772 of 1832 relevant lines covered (96.72%)

38.42 hits per line