mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-22 06:42:19 +03:00
7ac61b0f26
Three defects in the same known bug class produced the reported symptom (dashboard stuck on an old version while `omniroute update` says "already up to date"): - `omniroute update --apply` installed files and re-verified them on disk, but never restarted anything and its success message implied the running process was already current. It now checks the CLI's own PID file and prints an explicit instruction (`omniroute restart`, or `omniroute serve` when no server is detected) instead of implying the update is live. - The dashboard's npm-mode Update flow (`/api/system/version`) hardcoded `pm2 restart omniroute` at two duplicated call sites and silently degraded to a "skipped" status — reading like a completed update — whenever pm2 wasn't the process manager. A new `restartRunningServer()` helper (`src/lib/system/processManagerRestart.ts`) tries OmniRoute's own PID-file-managed supervisor first, then pm2, and reports an honest "restart-required" outcome otherwise. Both call sites now share one `sendRestartStep()` wrapper instead of duplicating the logic a third time. - `getLatestVersionFromNpmCli()` (backing the dashboard's update banner) ran `npm info` without `--prefer-online`, the same stale-npm-cache class already fixed in the CLI's own `getLatestVersion()` for #4376 but never mirrored here. The reporter's exact environment (install method, process manager) was never confirmed, so this fixes the mechanism, not a proven root cause for that specific user.