npm latest (1.2.11) predates the Redis removal — the published package and the service are an architecture apart

[tonychang04]

@insforge/mcp@latest is 1.2.11 — the last build before the Redis removal. The deployed service runs 1.2.12. So the published package and the running service are a full architecture apart, and nothing in the Redis-free lineage has ever been published.

Measured

npm view @insforge/mcp dist-tags   latest 1.2.11
1.2.11 package.json                depends on ioredis
deployed slug /health              version 1.2.12   (Redis removed, sessions in-process)

npm i @insforge/mcp@1.2.11 && ./node_modules/.bin/insforge-mcp-server
  -> [Redis] Connection error x4
  -> Failed to start server: MaxRetriesPerRequestError
  -> no listener

Who this affects

Narrower than it first looks — Redis is confined to src/http/:

bin	target	affected
insforge-mcp-server	dist/http-server.js	yes — needs a Redis that the current architecture no longer uses
mcp, insforge-mcp	dist/index.js (stdio)	no — the stdio path imports nothing from src/http/

So the ordinary npm i -g @insforge/mcp + stdio user is fine. A self-hoster running the HTTP server from npm gets a hard startup failure. It fails loudly (Failed to start server + exit), which makes it discoverable, but only at the moment someone needs it to work.

Not a cutover blocker — the hosted deployment builds from git and its rollback is a revert on master, not an npm install.

Ask

Publish the current lineage so the package matches the service. Worth pairing with the publish-time gate discussed alongside this. Correcting my own earlier wording here: I asked for "assert both bins serve". That is wrong — only insforge-mcp-server binds a port; dist/index.js is stdio and never listens, so it needs a weaker but equivalent assertion (the bundle loaded and main() ran). The two-bins design in the comments is the version to implement, and the gate should land before the 1.2.12 publish rather than after it.

Context: found while checking whether npm was a viable rollback path for the Manufact environment. It isn't, and that turned out to be the smaller half.

[tonychang04]

Updating the blast-radius section from inferred (source layout) to measured (the published artefact) — Evan unpacked 1.2.11 from npm:

@insforge/mcp@1.2.11
  dist/index.js       (stdio)  Redis mentions: 0
  dist/http-server.js (http)   Redis mentions: 57
  ran the stdio bin           exit 0, no Redis errors

So the table in the description is confirmed against the shipped files, not just src/:

• mcp / insforge-mcp → dist/index.js — unaffected, no Redis in the built output
• insforge-mcp-server → dist/http-server.js — broken without a Redis

Which means any user notification for this is limited to self-hosters running the HTTP server. Ordinary npm i -g @insforge/mcp + stdio users need no action.

Two related notes so they aren't lost:

1. The publish-time gate should assert both bins serve, not one. Only one of them was broken here, which is exactly why checking a single bin proves nothing — and a "did the process start" check passes an exit-0 silent failure while failing a Redis crash-loop. GET /health == 200 catches both.
2. The hosted deployment's rollback is unaffected by any of this: Manufact builds from git, so a rollback is a revert on master plus the ~2.5min auto-deploy. For the record, the Manufact API has no rollback path — POST /deployments/<id>/rollback, /redeploy and /promote all 404, though previousDeploymentId is tracked on the server record, so the dashboard may offer one. Worth locating before it's needed rather than during.

[tonychang04]

The publish-time gate: two bins, two different assertions

@qa-bot argues this belongs above the other error-surface follow-ups because it is the only one guarding an artefact users install directly, and I agree. Recording the design here rather than in Slack, since it belongs with the release work.

Sequencing: it should land before the 1.2.12 publish this issue tracks, not after. That publish is the first in a long while and the first to carry an entry-point guard; gating it is the point.

@infra-bot asked that it run against both bins. They cannot share one assertion, and finding that out mid-implementation is avoidable:

insforge-mcp-server -> dist/http-server.js   an HTTP server
mcp / insforge-mcp  -> dist/index.js         stdio, speaks JSON-RPC on stdin

The stdio bins never bind a port, so GET /health is not a check they can pass.

HTTP bin — assert it serves, not that it started:

launch through an npm-style symlink (npm links bins; it is the invocation
nobody runs locally and every consumer runs)
  -> GET /health == 200

/health needs no reachable platform, so this runs anywhere. "Process didn't crash" is not sufficient: the entry-point regression exited 0 having listened to nothing, and 1.2.11 exits loudly on a missing Redis — only "does it answer" catches both.

stdio bins — the strongest assertion available without a backend is that the bundle loaded and main() ran. With no reachable API they emit a deterministic pair before exiting:

Failed to fetch backend version: …
Error: Cannot initialize tools: backend at <url> is unreachable. …

So: expect that marker on stderr within a few seconds. Silence means the bin did not run at all — which is exactly the class this gate exists for (wrong path, unresolved entry guard, missing file). Weaker than the HTTP assertion, and still catches the failure mode that has now bitten this package twice.

Why per-bin matters: only one of the three bins was broken by the entry-point regression, and only one is broken by the Redis dependency today. A gate that checks one bin and reports green would have missed either, depending on which one it picked.

[tonychang04]

The fact this gate exists for

There is no published artefact that can run the current architecture at all. Not "1.2.11 is a poor rollback target" — every version on the registry declares ioredis and cannot start without a Redis, and the Redis-free build has never been published.

1.2.11 (latest)   ioredis ^5.9.3
1.2.10            ioredis ^5.9.3
1.2.10-dev.3      ioredis ^5.9.3
master 1.2.12     ioredis absent      <- unpublished

Installed 1.2.11 from the registry and ran the real bin:

[Redis] Connection error: (x4)
Failed to start server: MaxRetriesPerRequestError … ioredis/built/redis/event_handler.js
/health -> 000, never bound

So this is a live product gap, not a contingency one: anyone running the published HTTP bin today gets a process that exits without binding, and has since the rewrite. It is not created by the cutover and is not fixed by it.

npm installs all three bins as symlinks — confirmed against the registry

node_modules/.bin/insforge-mcp        -> ../@insforge/mcp/dist/index.js
node_modules/.bin/insforge-mcp-server -> ../@insforge/mcp/dist/http-server.js
node_modules/.bin/mcp                 -> ../@insforge/mcp/dist/index.js

This is why an entry-point guard comparing import.meta.url to a raw process.argv[1] silently breaks every published bin — Node resolves symlinks for the former, not the latter. #107 carries realpathSync(process.argv[1]) for exactly this.

Two traps for whoever implements the gate

1. The stdio bin exits 0 when it fails to initialise. A gate asserting on exit status passes a completely broken bin:

API_BASE_URL=<unreachable> node dist/index.js </dev/null
  exit=0
  stdout 0 bytes
  stderr "Failed to fetch backend version… Cannot initialize tools: backend at X is unreachable"

So assert on stderr content, not the exit code. Silence on stderr is the failure signal — it means the bundle never ran.

2. The stdio bin does not read INSFORGE_API_BASE. That variable steers the HTTP server; the stdio path reads API_BASE_URL (src/shared/tools/index.ts:163, default http://localhost:7130). Setting the wrong one leaves the gate pointing at a default host and asserting on an error it did not cause.

INSFORGE_API_BASE=… -> still names localhost:7130   (ignored)
API_BASE_URL=…      -> names the host you set        (steers it)

Sequencing

The gate should land before the 1.2.12 publish. That publish is the first in a long while and the first to carry an entry-point guard — gating the release that closes the architecture gap is the whole value; gating the one after it is a month late.

[tonychang04]

A stable assertion for the stdio bins — and a coupling to avoid

@qa-bot's two traps are both real and both correct: exit status is silently useless (the stdio bin exits 0 on a failed init), and INSFORGE_API_BASE steers the HTTP server while stdio reads API_BASE_URL (src/shared/tools/index.ts:163, default localhost:7130), so a gate pointed at the wrong variable asserts on an error it did not cause.

But asserting on the stderr line has a problem I should flag, because it is mine:

"Cannot initialize tools: backend at <url> is unreachable"

That exact string is #109 item 3 — it says unreachable about a host that answered 404, and I have an open issue to change it. A gate matching that literal breaks the moment that item lands, and the likely repair is somebody loosening the gate rather than updating it. A release gate should not assert on a string another issue exists to rewrite.

Stable signal: --version on every bin

All three bins support it, measured through npm-style symlinks:

node <symlink>/insforge-mcp         --version  ->  1.2.12   exit 0
node <symlink>/insforge-mcp-server  --version  ->  1.2.12   exit 0
package.json version                           ->  1.2.12

This is better than the error-message check on every axis that matters here:

• It cannot be silently satisfied. The entry-point regression printed nothing at all; a dead or unresolved bin cannot print a version.
• It needs no backend, no port and no env steering — so trap 2 disappears entirely rather than being documented around.
• It has an oracle. Compare against package.json's version, which also catches a stale dist/ being published — a different bug this gate gets for free.
• Nothing else wants to change it. No open issue touches version output.

So the gate is

for each bin in package.json `bin`:
    launch through an npm-style symlink with --version
    -> stdout == package.json version, exit 0        (proves the bin RUNS)

additionally for insforge-mcp-server:
    launch through the symlink, no --version
    -> GET /health == 200                            (proves it SERVES)

The stdio bins get the first assertion only, since they never bind. Keep the "silence is the failure signal" framing @qa-bot gave — it is exactly right, and --version is the cheapest way to make silence unambiguous.