The sync agent finds its modules by a route nobody can see

[sridharkalaibala]

Found by auditing the other packaging steps for the staleness trap that caused tonight's silent installer. This is not that trap, but it is the same family: correct code quietly relying on something invisible from where anybody is standing.

What is actually happening

The sync agent declares bson, dotenv and mongodb, and ships with none of them. Verified on the installed app here:

resources/sync-agent/
  package.json
  package-lock.json
  src/
  sync-config.json          <- no node_modules

And it works. The log shows it syncing: 91 order(s) arrived from the cloud, sync collections now 22.

The reason is three files apart from each other, none of which mentions the others:

1. src/server.js bootstraps the in-process API and puts the API's own node_modules on process.env.NODE_PATH. It does that for the API.
2. src/sync-agent-manager.js spawns the agent with ...process.env.
3. The agent inherits that NODE_PATH and resolves all three packages from the API's copy, which already carries every one of them.

So cloud sync depends on the API having started first, on a variable set for a different purpose, and on a spread operator that reads like boilerplate. Remove any one and it dies with MODULE_NOT_FOUND on a customer machine and nowhere else.

Why this is pinned and not rewired

Shipping a second copy of mongodb inside the installer, to duplicate one the API already has, would be real weight for no gain. The design is fine. The invisibility is the problem.

Cloud sync is load-bearing and this works today, so a test costs nothing while changing a working spawn costs a shop's orders if I get it wrong. Four tests hold the three links, including one that fails if the agent ever grows a dependency the API does not carry, which would otherwise surface as a sync that stopped, at night, on a till.

And a warning that fired when everything was right

The packaging step printed, on every correct build:

WARNING: agent copied without node_modules — run npm install in the Cloud agent first

Following that advice would have made every installer larger to fix nothing. A warning that fires when everything is right is one people learn to scroll past, and then the real one scrolls past too. It now says where the modules actually come from.

Zero assertion failures across the desktop suite.

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.