Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
29799
5e4f6989 Changed the frontend reload to drop lazy routers only after the settings read ref https://linear.app/ghost/issue/HKG-1823 - `reloadFrontend` called `urlService.facade.reset()` three lines before `await routeSettings.loadRouteSettings()`, leaving a window with no router configs for the length of that read — a network round trip on Pro - harmless while eager answered reads. Once lazy is authoritative it is not: `reset()` also clears `routersReady`, which gates the maintenance middleware, so the window 503s the site and the Admin API. Non-HTTP callers skip that gate entirely and would build URLs against zero routers - worse on the failure path: nothing re-registers after a failed reload, so a rejected settings read left the reset applied and 503ing with no recovery but a restart - moved the reset after the await, immediately before `siteApp.reload()`. It still runs before re-registration, so configs cannot pile up across reloads, and a failed read now leaves the previous routers serving - #29792 carries the same fix, but that is the eager removal and lands after this, which is the PR that makes the window harmful
by Princi Ver...
Succeeded
29799
d54c0ef3 Changed the frontend reload to drop lazy routers only after the settings read ref https://linear.app/ghost/issue/HKG-1823 - `reloadFrontend` called `urlService.facade.reset()` three lines before `await routeSettings.loadRouteSettings()`, leaving a window with no router configs for the length of that read — a network round trip on Pro - harmless while eager answered reads. Once lazy is authoritative it is not: `reset()` also clears `routersReady`, which gates the maintenance middleware, so the window 503s the site and the Admin API. Non-HTTP callers skip that gate entirely and would build URLs against zero routers - worse on the failure path: nothing re-registers after a failed reload, so a rejected settings read left the reset applied and 503ing with no recovery but a restart - moved the reset after the await, immediately before `siteApp.reload()`. It still runs before re-registration, so configs cannot pile up across reloads, and a failed read now leaves the previous routers serving - #29792 carries the same fix, but that is the eager removal and lands after this, which is the PR that makes the window harmful
by Princi Ver...
Succeeded
29799
eb2be520 Changed the URL force-load to leave a read's lookup keys alone ref https://linear.app/ghost/issue/HKG-1823 - #29797 landed on main while this branch was out and established the rule: `findOne` forges the model with its lookup keys before the fetch, so a read already carries them, and forcing them in means stripping a field the caller is served today. It applied that to `id` only - the same holds for every other lookup key, and lazy needs `slug` for the permalink — so `posts/slug/:slug/?fields=title,url` was force-loading a slug the model already had and then stripping it back out, dropping a field from the response that eager serves - generalised the `id` carve-out to every key in `frame.data`, which folds the two mechanisms into one and leaves the Content API response unchanged - the assertions under `forceUrlRelationsWhenLazy` still pinned the array shape of `forcedUrlColumns` from before it carried its `routerType`; updated to match the rest
by Princi Ver...
Succeeded
29799
eb2be520 Changed the URL force-load to leave a read's lookup keys alone ref https://linear.app/ghost/issue/HKG-1823 - #29797 landed on main while this branch was out and established the rule: `findOne` forges the model with its lookup keys before the fetch, so a read already carries them, and forcing them in means stripping a field the caller is served today. It applied that to `id` only - the same holds for every other lookup key, and lazy needs `slug` for the permalink — so `posts/slug/:slug/?fields=title,url` was force-loading a slug the model already had and then stripping it back out, dropping a field from the response that eager serves - generalised the `id` carve-out to every key in `frame.data`, which folds the two mechanisms into one and leaves the Content API response unchanged - the assertions under `forceUrlRelationsWhenLazy` still pinned the array shape of `forcedUrlColumns` from before it carried its `routerType`; updated to match the rest
by Princi Ver...
Succeeded
29799
eb2be520 Changed the URL force-load to leave a read's lookup keys alone ref https://linear.app/ghost/issue/HKG-1823 - #29797 landed on main while this branch was out and established the rule: `findOne` forges the model with its lookup keys before the fetch, so a read already carries them, and forcing them in means stripping a field the caller is served today. It applied that to `id` only - the same holds for every other lookup key, and lazy needs `slug` for the permalink — so `posts/slug/:slug/?fields=title,url` was force-loading a slug the model already had and then stripping it back out, dropping a field from the response that eager serves - generalised the `id` carve-out to every key in `frame.data`, which folds the two mechanisms into one and leaves the Content API response unchanged - the assertions under `forceUrlRelationsWhenLazy` still pinned the array shape of `forcedUrlColumns` from before it carried its `routerType`; updated to match the rest
by Princi Ver...
Succeeded
29799
eb2be520 Changed the URL force-load to leave a read's lookup keys alone ref https://linear.app/ghost/issue/HKG-1823 - #29797 landed on main while this branch was out and established the rule: `findOne` forges the model with its lookup keys before the fetch, so a read already carries them, and forcing them in means stripping a field the caller is served today. It applied that to `id` only - the same holds for every other lookup key, and lazy needs `slug` for the permalink — so `posts/slug/:slug/?fields=title,url` was force-loading a slug the model already had and then stripping it back out, dropping a field from the response that eager serves - generalised the `id` carve-out to every key in `frame.data`, which folds the two mechanisms into one and leaves the Content API response unchanged - the assertions under `forceUrlRelationsWhenLazy` still pinned the array shape of `forcedUrlColumns` from before it carried its `routerType`; updated to match the rest
by Princi Ver...
Failed
29799
3c47c0dc Changed the URL service to answer from lazy everywhere ref https://linear.app/ghost/issue/HKG-1823/ - shadow comparison ran across Ghost(Pro) for the observation window, so lazy becomes the answer source rather than a shadow. `compare: false` is the switch; the `lazyRouting` gate goes too, so no configuration is left in which this is untested. Eager is still built but unread, until HKG-1824 deletes it - dynamic routing now runs on every boot. It mounts routers on the site app and registers them with the URL service; only the first needs a frontend, and the second is needed wherever URLs are built — which includes the APIs. Without it a backend-only boot has no routers and resolves everything to /404/ - upload readiness reads the facade. With lazy authoritative the facade registers routers on lazy alone, so eager never gets a url generator, its init queue never emits `ended`, and its `finished` stays false — which would roll back every routes.yaml upload - a thin resource degrades to /404/ under LAZY_URL_RESOLUTION_ERROR instead of 500ing. Only that class; anything else is a backend bug and propagates, since a silent /404/ on a page that does route gets indexed - forced URL columns now carry the fetch they were computed for. The posts mapper passes its own frame to the nested tag and author mappers, and those resources share `slug`/`status` with posts, so each was deleting the other's fields off data the caller asked for - e2e snapshots move from /404/ to real URLs. Backend-only boots read URLs from a 2021 fixture only eager can load, so the snapshots were asserting that file, not URL generation — one even pinned Joe Bloggs' URL on a user whose slug is `test`. Empty tags and authors keep lazy's real URL per HKG-1920
by Princi Ver...
Failed
29799
3c47c0dc Changed the URL service to answer from lazy everywhere ref https://linear.app/ghost/issue/HKG-1823/ - shadow comparison ran across Ghost(Pro) for the observation window, so lazy becomes the answer source rather than a shadow. `compare: false` is the switch; the `lazyRouting` gate goes too, so no configuration is left in which this is untested. Eager is still built but unread, until HKG-1824 deletes it - dynamic routing now runs on every boot. It mounts routers on the site app and registers them with the URL service; only the first needs a frontend, and the second is needed wherever URLs are built — which includes the APIs. Without it a backend-only boot has no routers and resolves everything to /404/ - upload readiness reads the facade. With lazy authoritative the facade registers routers on lazy alone, so eager never gets a url generator, its init queue never emits `ended`, and its `finished` stays false — which would roll back every routes.yaml upload - a thin resource degrades to /404/ under LAZY_URL_RESOLUTION_ERROR instead of 500ing. Only that class; anything else is a backend bug and propagates, since a silent /404/ on a page that does route gets indexed - forced URL columns now carry the fetch they were computed for. The posts mapper passes its own frame to the nested tag and author mappers, and those resources share `slug`/`status` with posts, so each was deleting the other's fields off data the caller asked for - e2e snapshots move from /404/ to real URLs. Backend-only boots read URLs from a 2021 fixture only eager can load, so the snapshots were asserting that file, not URL generation — one even pinned Joe Bloggs' URL on a user whose slug is `test`. Empty tags and authors keep lazy's real URL per HKG-1920
by Princi Ver...