2GT-RichandClaude Opus 5
8474f8e789
Reported as rollouts failing with "Device rebooted but still reports 7.24.1 — the update did not apply", intermittently and on ad-hoc updates too. Three separate faults, found by watching one rollout that succeeded on an access point and failed on a switch in the same run. **The device had never rebooted.** Its uptime was one week. The old sequence issued `/system/package/update/install`, slept a fixed 25 seconds, reconnected, read the version and — finding it unchanged — declared the upgrade failed. It could not tell a device that restarted unchanged from one that never restarted at all, and 25 seconds is nowhere near long enough: the access point that *worked* took 245 seconds. So a device still busy downloading was routinely reported as broken, and with halt-on-failure that aborted the rest of the fleet. **`install` was the wrong command.** It bundles download and reboot into one fire-and-forget call whose progress cannot be observed. On the CCR2216 it accepted the command and then neither downloaded nor rebooted, reporting nothing; an explicit `download` on the same device worked immediately. The sequence is now download → confirm the device reports the image as downloaded → reboot, which makes success verifiable *before* anything restarts and means a device is never rebooted for an image it does not have. **A successful reboot was being read as a failure.** Rebooting necessarily kills the session that asked for it, so the transport error that follows is the expected outcome. Unhandled, it surfaced as "Update failed before reboot: Connection closed" on a device that had in fact rebooted and upgraded correctly. The reboot is now proven by comparing uptime across it rather than assumed from elapsed time, so "never restarted" is reported as itself — with the device left running and reachable — instead of being mistaken for a failed upgrade. Download failures now carry the device's free space, because that is the usual cause and "did not finish in ten minutes" otherwise sends someone hunting the network. A CRS309 with 1.06 MB free now says so instead of timing out silently. Verified on hardware: the CCR2216 that produced the original report upgraded 7.24.1 to 7.24.2 cleanly, and the CRS309 that genuinely cannot fit the image failed with an accurate message and was left untouched — same version, uptime unbroken, never rebooted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
50 lines
1.3 KiB
JSON
50 lines
1.3 KiB
JSON
{
|
|
"name": "mikrotik-manager-frontend",
|
|
"version": "0.23.31-beta",
|
|
"private": true,
|
|
"type": "module",
|
|
"scripts": {
|
|
"dev": "vite",
|
|
"build": "tsc && vite build",
|
|
"preview": "vite preview",
|
|
"lint": "eslint src",
|
|
"test": "vitest run"
|
|
},
|
|
"dependencies": {
|
|
"@tanstack/react-query": "^5.101.0",
|
|
"@types/leaflet": "^1.9.21",
|
|
"@xterm/addon-fit": "^0.11.0",
|
|
"@xterm/xterm": "^6.0.0",
|
|
"@xyflow/react": "^12.11.1",
|
|
"axios": "^1.18.1",
|
|
"clsx": "^2.1.0",
|
|
"date-fns": "^3.2.0",
|
|
"leaflet": "^1.9.4",
|
|
"lucide-react": "^1.23.0",
|
|
"react": "^19.2.7",
|
|
"react-dom": "^19.2.7",
|
|
"react-router-dom": "^7.18.1",
|
|
"recharts": "^2.10.3",
|
|
"socket.io-client": "^4.7.3",
|
|
"tailwind-merge": "^3.5.0",
|
|
"zustand": "^4.4.7"
|
|
},
|
|
"devDependencies": {
|
|
"@eslint/js": "^9.39.4",
|
|
"@types/react": "^19.2.14",
|
|
"@types/react-dom": "^19.2.3",
|
|
"@vitejs/plugin-react": "^6.0.3",
|
|
"autoprefixer": "^10.4.17",
|
|
"eslint": "^9.39.4",
|
|
"eslint-plugin-react": "^7.37.5",
|
|
"eslint-plugin-react-hooks": "^7.0.1",
|
|
"eslint-plugin-security": "^4.0.0",
|
|
"postcss": "^8.5.10",
|
|
"tailwindcss": "^3.4.1",
|
|
"typescript": "^5.9.3",
|
|
"typescript-eslint": "^8.58.2",
|
|
"vite": "^8.0.16",
|
|
"vitest": "^4.1.8"
|
|
}
|
|
}
|