Loading workspace insights... Statistics interval
7 days30 daysLatest CI Pipeline Executions
fa31af63 Added legacy validation fallback to the route settings read path
- an audit of 41,346 Pro routes.yaml files found 97 that the stricter
parser rejects but the legacy validator accepts — live sites that
would fail to boot at rollout. The read path now falls back to the
legacy validator for those files, logging
ROUTE_SETTINGS_VALIDATION_FALLBACK with the reason so they get fixed
- only validation failures fall back — IO and parse errors surface
unchanged, since the legacy loader would fail on those too and only
mask the real error. The fallback reads local disk, so it only
functions while FileStore is the active store
- fallback sites stay fully operational: download returns the raw file
(it's the file the operator needs to fix), and uploading a corrected
file is not blocked by the invalid current one — the upload proceeds
without a rollback snapshot, relying on the store's own timestamped
backup of the raw file. Uploads themselves stay strict-only, so the
fallback population can only shrink
- a failed frontend reload no longer rolls the store back: validation
happens before persistence now, so a reload failure isn't caused by
the routes and re-running a failing reload to restore them helps
nobody. The isBlogRunning timeout path still rolls back, since a hang
can be routes-induced
- reloadFrontend takes its routeSettings and urlService dependencies as
arguments now, removing the bridge ↔ route-settings circular require
- settings-loader, validate.js and settings-path-manager return to
active use until the fallback is retired bc8b960c Added legacy validation fallback to the route settings read path
- an audit of 41,346 Pro routes.yaml files found 97 that the stricter
parser rejects but the legacy validator accepts — live sites that
would fail to boot at rollout. The read path now falls back to the
legacy validator for those files, logging
ROUTE_SETTINGS_VALIDATION_FALLBACK with the reason so they get fixed
- only validation failures fall back — IO and parse errors surface
unchanged, since the legacy loader would fail on those too and only
mask the real error. The fallback reads local disk, so it only
functions while FileStore is the active store
- fallback sites stay fully operational: download returns the raw file
(it's the file the operator needs to fix), and uploading a corrected
file is not blocked by the invalid current one — the upload proceeds
without a rollback snapshot, relying on the store's own timestamped
backup of the raw file. Uploads themselves stay strict-only, so the
fallback population can only shrink
- a failed frontend reload no longer rolls the store back: validation
happens before persistence now, so a reload failure isn't caused by
the routes and re-running a failing reload to restore them helps
nobody. The isBlogRunning timeout path still rolls back, since a hang
can be routes-induced
- reloadFrontend takes its routeSettings and urlService dependencies as
arguments now, removing the bridge ↔ route-settings circular require
- settings-loader, validate.js and settings-path-manager return to
active use until the fallback is retired d1ae209f Switched route settings to read through the configured store
- boot, reload, upload and download now go through the adapter-manager provided store instead of the legacy SettingsLoader/RouteSettings file handling — the storage backend is fully config-selected, so the remote store becomes a config flip with no further service changes
- the activation bridge goes live here: loadRouteSettings expands the domain model into the router format, and getCurrentHash keeps the exact legacy algorithm (md5 over the stringified expansion). Sites on default routes keep their routes_hash; sites with custom routes recompute it once at cutover because the legacy hash embedded the operator's YAML key order — routes_hash has no readers beyond self-comparison in syncRoutesHash, so the effect is one silent settings update per site. New determinism tests pin the guarantee that matters now: the same config always hashes identically, regardless of YAML key order
- uploads are parsed and validated before anything is persisted — an invalid routes.yaml is rejected without touching the store, instead of being written and rolled back after a failed frontend reload. Rollback after a failed reload is now a store replace of the previous settings
- boot no longer seeds routes.yaml into content/settings — the store's empty state serves the bundled defaults from memory, so fresh installs work on read-only filesystems; downloads still return the default YAML
- the legacy modules (settings-loader, route-settings, settings-path- manager, default-settings-manager) are now unreferenced