Conversation
The golden CertificationData vectors both SDKs carry pin what goes to the aggregator, and they are byte-identical. They stayed that way through the whole of 3.0.0 — including while the Java SDK could not read a token this one produced, because Token and the certified transactions inside it are not part of what those vectors cover. So: each SDK builds a token from entirely fixed inputs — keys, salt, token type, state mask, deadline and the fake aggregator's round clock, with RFC 6979 signing on both sides — commits it, and decodes and fully verifies the other's. Regenerate with `INTEROP_WRITE=true npm run test:interop`; the committed bytes are what the Java suite reads, so moving them is a deliberate act. The two SDKs' UnicityCertificate test fixtures differ in three padding fields, so a shared token hex vector is not possible. It is not needed: each side reads the producer's certificate and trust base out of the fixture bundle. The vectors run in test:ci with no infrastructure. The matching Java half is unicitynetwork/state-transition-sdk-java#84.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 49e24f28b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| describe('Interop with a token produced by the Java SDK', () => { | ||
| const present = hasVector(TOKEN); | ||
|
|
||
| (present ? it : it.skip)( |
There was a problem hiding this comment.
Fail when the Java interop vector is missing
If java-token-v2.cbor is deleted, omitted from a checkout, or renamed, this conditional converts the core consuming-side interoperability check into a skipped test, and the repository's npm run test:ci workflow still succeeds. Because this is a required committed fixture, run the test unconditionally (or explicitly assert the fixture exists) so losing the vector cannot silently remove the Java-to-JS coverage.
Useful? React with 👍 / 👎.
|
Not needed. The Java repo can do the whole thing itself: the npm package ships only |
The TypeScript half of the cross-SDK interop vectors. The Java half is unicitynetwork/state-transition-sdk-java#84.
Why
Both SDKs already carry golden
CertificationDatavectors, and they are byte-identical. They stayed that way through the whole of 3.0.0 — including while the Java SDK could not read a token this one produced.Tokenand the certified transactions inside it are simply not part of what those vectors cover, so the divergence was invisible to every cross-SDK test that existed.Concretely, with
Token.VERSIONreverted to 1 on the Java side:How
Each SDK builds a token from entirely fixed inputs — keys, salt, token type, state mask, deadline and the fake aggregator's round clock, with RFC 6979 signing on both sides — commits the bytes, and decodes and fully verifies the other's.
TestAggregatorClient.setReferenceTime, added in #147, is what makes the generated vector byte-reproducible rather than dependent on when it ran.Two tests here:
InteropVectorTest— the producing half. Regenerating must reproduce the committed bytes, and the container shape is pinned explicitly (Token.version === 2n, one transfer, deadline and reference time survive the round trip). Regenerate deliberately withINTEROP_WRITE=true npm run test:interop; those bytes are what the Java suite reads.JavaProducedTokenTest— the consuming half. A Java-produced token decodes, verifiesOKunder the Java trust base, and reports the deadline and reference time the transaction hash commits to.The two SDKs'
UnicityCertificatetest fixtures differ in three padding fields, so a shared token hex vector is not possible. It is not needed: each side reads the producer's certificate and trust base out of the fixture bundle.Verification
build:checkandlintclean. 195 tests pass intest:ci— 192 before, plus these 3. The vectors need no infrastructure, so they run in the ordinary CI job with the unit and functional suites; no workflow change.Verified in both directions with neither test skipped, and container prefixes byte-identical across the two SDKs:
d99880 83 02 82 d99881 88 02 03.