2GT-RichandClaude Opus 5
d9fa120abc
Follows #137. The v0.24.1 fix made the count honest and stopped a thousand round trips per poll, but it assumed the unique index on (device_id, log_id) would reject lines already stored. For most devices it does. For a device whose log entries carry no `.id` it never could: the column was set to NULL, and PostgreSQL treats NULLs as *distinct* in a unique index, so every NULL conflicts with nothing. Those devices re-inserted their entire buffer on every poll, for ever, and the constraint that was supposed to stop it was structurally incapable of firing. A line with no id now gets a key derived from its own content -- timestamp, topics and message -- so the existing index does the work. The `#` prefix keeps it out of the space of real RouterOS ids (`*` plus hex), so the two cannot collide, and parseRosId already rejects it, which matters because the watermark is a max over real ids and must not be poisoned by a synthetic one. The trade, stated rather than buried: two genuinely separate lines sharing a timestamp, topic and message collapse into one. RouterOS timestamps are second-resolution, so that can happen. Losing a repeat of an identical message is a much smaller loss than growing the table by the whole buffer every minute without bound. This was found by reading a comment on #137 I had not read before closing it -- log output from a device with eleven lines total, reporting eleven new entries every minute for forty-five minutes. My own fleet cannot reproduce it: every event here carries a real `.id`, with no nulls and no duplicates, which is exactly why the hole was invisible from here. So this closes a defect demonstrable from the schema; whether it is the whole of that reporter's problem is still an open question and the issue is reopened to ask. Verified no regression where ids are healthy: no surrogate keys generated, no nulls, no duplicates, and counts that vary with real activity. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
1.7 KiB
JSON
63 lines
1.7 KiB
JSON
{
|
|
"name": "mikrotik-manager-backend",
|
|
"version": "0.24.4-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.81.2",
|
|
"compression": "^1.7.4",
|
|
"cors": "^2.8.5",
|
|
"dotenv": "^17.4.2",
|
|
"express": "^4.18.2",
|
|
"express-async-errors": "^3.1.1",
|
|
"helmet": "^8.3.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.22.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.1",
|
|
"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"
|
|
}
|
|
}
|