A deploy that stalled on Node, and a Mongoose warning cleaned up
One package in the dependency batch shipped from earlier today assumed a newer Node than the server runs, which stopped a deploy in its tracks. Fixed within the hour, plus a cleanup of a Mongoose warning that had been showing up in every log line.
Highlights
- Isolated-vm reverted to 6.1.2: its 7.x line requires Node 24, the server runs Node 22, and the deploy refused to install until this was caught
- The fix shipped and was redeployed the same hour, verified against a live health check and a clean process log
- The Mongoose new:true deprecation warning is gone from the logs for good, across all 48 places it was showing up
In this release2
- FixedSystemHigh impact
Isolated-vm reverted to 6.1.2 after it stalled a production deploy
Today's dependency upgrade bumped isolated-vm, used to run automation flow "code" nodes in a sandbox, from 6.1.2 to 7.0.1. That passed cleanly in local development, where Node 24 is installed, but the production server runs Node 22.16.0, and isolated-vm 7.x hard-requires Node 24 or newer. The next deploy refused to install with the dependency install step failing outright, which is the safe way for this kind of mismatch to fail: the old build kept running the whole time, nothing customer facing went down.
What we changed:
- isolated-vm was reverted to 6.1.2, which only requires Node 22 and up and is the version that had already been running in production before today's batch.
- The fix was committed, pushed and redeployed within the hour. The deploy was verified against pm2 status, a clean process log (Mongo, Redis and the mail server all connecting normally) and a direct hit against the API's own status endpoint.