Files
MIKROTIK-RMM/backend/package.json
T
2GT-RichandClaude Opus 5 deb71363c9 fix(poller): cap Redis memory, and stop retrying periodic polls (v0.23.18-beta)
The two follow-ups left open by v0.23.17. One is a real fix; the other turned
out to need explaining rather than fixing.

**Redis had no memory ceiling.** v0.23.17 stopped the poller from growing Redis
without bound, but nothing stopped anything else from doing so, and the host had
no protection either way. Redis now runs with a 512 MB cap (REDIS_MAXMEMORY).

The eviction policy is the part worth care. `allkeys-lru` would be actively
dangerous here: BullMQ job data carries no TTL, so an LRU sweep across all keys
could discard queued work with no trace. `volatile-lru` evicts only keys that
set an expiry — which is exactly the poller's caches and in-flight claims, all
of which are safe to lose because losing one merely causes an earlier re-poll.
Verified rather than assumed: sampled BullMQ job keys report ttl=-1 and poller
cache keys 528-3408s. If pressure ever exhausts the volatile keys Redis refuses
writes instead of evicting queue state, which is loud and survivable.

**The 14% fast-poll failure rate is not a bug.** Current rate across all devices
and job kinds is 0% over 1,462 attempts. The historical 230,707 failures were
genuine device downtime: device_availability records 324 outages totalling ~1,003
hours across four lab devices, which at a 30-second cadence and two attempts per
cycle predicts ~240,700 failures — within 4% of what was recorded. Nothing to
fix; retention had simply been hoarding an accurate count.

It did expose real waste, though. Periodic polls no longer retry in-job, because
the schedule already is the retry: a device that did not answer is unlikely to
answer a second later, and each extra attempt occupies a worker for up to the
job timeout. On a fleet with several devices down that doubled the capacity they
consumed — the same capacity the rest of the fleet was short of in #114. It also
doubled the recorded failure count, which is how ~1,000 hours of downtime came
to look like 231k distinct faults. User-initiated full syncs keep their retries.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 20:20:56 -07:00

63 lines
1.7 KiB
JSON

{
"name": "mikrotik-manager-backend",
"version": "0.23.18-beta",
"description": "Mikrotik Network Management Platform - Backend API",
"main": "dist/index.js",
"scripts": {
"build": "tsc",
"start": "node dist/index.js",
"dev": "nodemon --watch src --ext ts --exec ts-node src/index.ts",
"lint": "eslint src",
"migrate": "ts-node src/db/migrate.ts",
"test": "jest",
"test:coverage": "jest --coverage"
},
"dependencies": {
"@influxdata/influxdb-client": "^1.33.2",
"@influxdata/influxdb-client-apis": "^1.35.0",
"bcryptjs": "^2.4.3",
"bullmq": "^5.1.1",
"compression": "^1.7.4",
"cors": "^2.8.5",
"dotenv": "^17.4.2",
"express": "^4.18.2",
"express-async-errors": "^3.1.1",
"helmet": "^8.1.0",
"ioredis": "^5.10.1",
"jsonwebtoken": "^9.0.2",
"morgan": "^1.10.0",
"nodemailer": "^9.0.3",
"openid-client": "^5.7.1",
"otpauth": "^9.5.1",
"pg": "^8.21.0",
"qrcode": "^1.5.4",
"socket.io": "^4.6.1",
"ssh2": "^1.14.0"
},
"devDependencies": {
"@eslint/js": "^10.0.1",
"@types/bcryptjs": "^2.4.6",
"@types/compression": "^1.7.5",
"@types/cors": "^2.8.17",
"@types/express": "^4.17.21",
"@types/jest": "^30.0.0",
"@types/jsonwebtoken": "^9.0.5",
"@types/morgan": "^1.9.9",
"@types/node": "^26.1.1",
"@types/nodemailer": "^6.4.14",
"@types/pg": "^8.10.9",
"@types/qrcode": "^1.5.6",
"@types/ssh2": "^1.11.17",
"@types/supertest": "^7.2.0",
"eslint": "^10.7.0",
"eslint-plugin-security": "^4.0.1",
"jest": "^30.4.2",
"nodemon": "^3.0.2",
"supertest": "^7.2.2",
"ts-jest": "^29.4.9",
"ts-node": "^10.9.2",
"typescript": "^6.0.3",
"typescript-eslint": "^8.64.0"
}
}