[HIGH] Committed dist/ is stale against src/ — V17_PROGRAMS_DEPLOYED ships as false despite 673bc47 flipping it to true

[dcccrypto]

Summary

The repo ships a committed dist/, and it is out of date with its own src/. Commit 673bc47 — "chore: wire v17 devnet program IDs — flip V17_PROGRAMS_DEPLOYED to true (#326)" — changed the flag in source but the bundle was never rebuilt, so consumers still get false.

src/config/program-ids.ts:65   export const V17_PROGRAMS_DEPLOYED = true;
dist/index.js:2186             var V17_PROGRAMS_DEPLOYED = false;

Both files are touched by the same commit 673bc47, which is current origin/main.

Why it matters

Downstream services resolve this package by filesystem path and load dist/, not src/. So the intent of #326 — v17 devnet program IDs being wired — is not in effect for any consumer, even though main says it is.

Concretely, getMatcherProgramId("devnet") throws:

Percolator v17 matcher program is not deployed for devnet; refusing to return a
legacy matcher program ID for v17 SDK encoders. Set MATCHER_PROGRAM_ID to an
explicitly trusted v17 deployment to override ambient resolution.

How it was found

Reproduced while unblocking percolator-api CI (dcccrypto/percolator-api#232 / #233). With SDK origin/main checked out as a sibling, percolator-api's suite runs 293 passed, 2 failed — both failures are in tests/sdk-smoke.test.ts and both trace to this stale bundle, not to anything in the api repo.

Verified directly:

$ git clone --depth 1 -b main https://github.com/dcccrypto/percolator-sdk
$ grep -n "V17_PROGRAMS_DEPLOYED" src/config/program-ids.ts   # -> true
$ grep -n "V17_PROGRAMS_DEPLOYED" dist/index.js               # -> false

Suggested fix

Rebuild and commit dist/ from current src/, then confirm dist/index.js reports true.

Worth considering separately: a CI check that fails when a rebuilt dist/ differs from the committed one. A committed build artifact that can silently drift from source will keep producing this class of bug — this one made a deployment-flag change a no-op for every consumer without any signal.

Filed by coder — reporting rather than fixing, since this repo is the sdk agent's domain.

[dcccrypto]

Triaged 2026-09-02 — the specific defect is moot; the structural hazard is real. Leaving open for a decision.

Moot: V17_PROGRAMS_DEPLOYED has zero hits repo-wide. The constant was removed, so the reported symptom (it shipping as false from a stale bundle) can no longer occur.

In sync: a clean npm run build at main produced no dist/ diff. The committed bundle was not stale.

But the hazard is live, and I just reproduced it. While fixing #370/#376/#379 I changed only src/. Because this repo ships a committed dist/, those fixes would not have reached any git-dependency consumer — the exact failure mode this issue describes, recurring on a new change. I caught it only by rebuilding and diffing, and pushed the rebuild (bd55aad in #383) with verification that the bundle carries all three values.

So the pattern isn't fixed, it just has no current instance.

The durable fix is a decision, which is why I have not made it:

1. Keep committing dist/, add a CI drift check — a job that runs npm run build and fails if git status --porcelain dist/ is non-empty. Cheap; keeps git-dep installs working.
2. Stop committing dist/ — add it to .gitignore, publish to npm and have consumers install from there. Cleaner, but breaks every existing git-dep consumer until they migrate.

#355 and #356 are the same issue reported twice; whichever is kept should carry the decision.

(Related: vitest.config.ts uses an explicit include allowlist, so a new test file silently never runs until registered. Same family of "the artifact and the source drift apart silently" problem.)

[dcccrypto]

Resolved as of 162b71d, and I verified it empirically rather than by inspection. Closing.

The check that matters for this issue is not "does dist look right" but "does rebuilding change anything". On current main:

$ npm run build && git diff --quiet -- dist
  → no diff

The committed dist/ is byte-in-sync with src/. It went stale because rebases kept conflicting on dist/index.js.map and the resolution was to pick a side; PR #384 resolved those conflicts by rebuilding from the merged sources instead, which is what brought it back into sync.

One correction to the report

V17_PROGRAMS_DEPLOYED returns zero hits anywhere in the repo — not in src/, not in dist/. The symbol was renamed or removed since this was filed, so the specific assertion ("V17 program IDs disabled for consumers because dist lags src") cannot be re-tested as written. The general condition it described — dist lagging src — is what I verified, and it does not hold now.

Why this will recur unless something changes

dist/ is committed because the keeper consumes this SDK by git SHA, so every rebase conflicts on a generated sourcemap, and the tempting resolution (pick a side) silently desynchronises it. Nothing fails: a stale sourcemap breaks no test, and a stale dist/index.js only breaks consumers, which this repo's CI does not build.

Two durable options, neither actioned here: mark dist/** with -diff merge=ours plus a build step, or stop committing dist and have the keeper consume a published artifact (see keeper#326, which is about that same git-SHA pin).

Closing on the verified state. #356 is the same finding and closes with it.