Skip to content

Add cross-SDK interop vectors against the Java SDK - #149

Closed
MastaP wants to merge 1 commit into
mainfrom
interop/java-cross-sdk-vectors
Closed

MastaP wants to merge 1 commit into
mainfrom
interop/java-cross-sdk-vectors

Conversation

@MastaP

@MastaP MastaP commented Aug 27, 2026

Copy link
Copy Markdown
Member

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 CertificationData vectors, 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. Token and 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.VERSION reverted to 1 on the Java side:

CrossSdkEncodingTest:  0 failures / 2     ← existing cross-SDK test
InteropVectorTest:     1 failure  / 2     ← added here
JsProducedTokenTest:   1 failure  / 1     ← added here

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 with INTEROP_WRITE=true npm run test:interop; those bytes are what the Java suite reads.
  • JavaProducedTokenTest — the consuming half. A Java-produced token decodes, verifies OK under the Java trust base, and reports the deadline and reference time the transaction hash commits to.

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.

Verification

build:check and lint clean. 195 tests pass in test: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.

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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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)(

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

@MastaP

MastaP commented Aug 27, 2026

Copy link
Copy Markdown
Member Author

Not needed. The Java repo can do the whole thing itself: the npm package ships only lib/, so nothing here is required to produce a token for it to verify — and generating one against the published artifact, rather than this repo's source tree, is the more faithful test anyway. Superseded by a live interop step in unicitynetwork/state-transition-sdk-java#84.

@MastaP MastaP closed this Aug 27, 2026
@MastaP
MastaP deleted the interop/java-cross-sdk-vectors branch August 27, 2026 10:49
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.

1 participant