Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
30722
f8de8e63 Fixed frozen config rejecting required() and handing back mutable objects no ref Two problems with the freeze helper, both found in review. required() was in the mutator list, but it isn't one: nconf implements it as a read - it calls get() for each key and throws when one is missing. Blocking it would have made post-load config validation throw "Config is frozen" in every non-test environment. It's out of the list, with a test covering both the passing and missing-key cases while frozen. Object-valued reads were cached and handed back by reference, so a caller that mutated what it got rewrote the cache for every later reader. configure() in data/db/connection.js does exactly that - it assembles the knex config by mutating the object it's passed, which is config.get('database'). That made the two ways of reading a key disagree: get('database').pool -> {} (whatever knex bootstrap bolted on) get('database:pool') -> undefined (no store has it) Cached values are now deep-frozen, so a mutation raises a TypeError naming the site instead of silently corrupting config, and configure() clones before mutating. The clone is worth having on its own: mutating the object config handed back was already writing through to nconf's stores for nested keys, since nconf's merge shares subtrees by reference. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude
Succeeded
30722
12b416ab Fixed frozen config rejecting required() and handing back mutable objects no ref Two problems with the freeze helper, both found in review. required() was in the mutator list, but it isn't one: nconf implements it as a read - it calls get() for each key and throws when one is missing. Blocking it would have made post-load config validation throw "Config is frozen" in every non-test environment. It's out of the list, with a test covering both the passing and missing-key cases while frozen. Object-valued reads were cached and handed back by reference, so a caller that mutated what it got rewrote the cache for every later reader. configure() in data/db/connection.js does exactly that - it assembles the knex config by mutating the object it's passed, which is config.get('database'). That made the two ways of reading a key disagree: get('database').pool -> {} (whatever knex bootstrap bolted on) get('database:pool') -> undefined (no store has it) Cached values are now deep-frozen, so a mutation raises a TypeError naming the site instead of silently corrupting config, and configure() clones before mutating. The clone is worth having on its own: mutating the object config handed back was already writing through to nconf's stores for nested keys, since nconf's merge shares subtrees by reference. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude
Succeeded
30722
97f5b224 Removed the config freeze opt-out flag no ref optimization.freezeConfig was added as a kill switch for freezing config, on the grounds that freezing makes config throw in production. On reflection it earns its config surface: nothing in the tree writes to config after load, so the flag only exists to re-enable a behaviour we don't want back, and a config key to control config's own loading is an awkward thing to reason about. defaults.json is now untouched by this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude
Succeeded
30722
ba523372 Added a freeze helper that makes config read-only once loaded no ref Config is fully loaded by the time loadNconf() returns, and nothing in Ghost writes to it afterwards, but nconf doesn't know that. Every config.get() walks all nine stores, and for an object-valued key it collects a hit from each one and deep-merges them - on every single call. There are 353 get call sites in core, some on per-request paths. freeze() makes the instance read-only and memoises get() by key. Because each cached value is whatever nconf itself returned for that key, a frozen lookup can't disagree with an unfrozen one, and with writes rejected a cache entry can't go stale - so there's no invalidation to get wrong. Measured against the real config: get('database') 3526ns -> 15ns, getSiteUrl() 1276ns -> 63ns. The mutators throw rather than no-op. nconf's own readOnly flag would have been the obvious lever, but Provider._execute *skips* read-only stores for a destructive action and returns undefined, which turns a config write into a silent failure instead of a loud one. loadNconf freezes as its last step rather than leaving it to boot, so a write during boot fails loudly instead of quietly working. Nothing in the tree does that today - the last two runtime writes were the asset hash, moved into the asset hash service - so this holds the line rather than changing behaviour. It's skipped under test, where the suites rewrite config between cases on purpose, and optimization.freezeConfig turns it off entirely. A keyless get() is left uncached. nconf's env store holds the whole environment, so the merged tree materialises it - on a boot here, 139 of 194 top-level keys came from env rather than config - and caching that would mean a long-lived object holding every environment variable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude
Succeeded
30722
ba523372 Added a freeze helper that makes config read-only once loaded no ref Config is fully loaded by the time loadNconf() returns, and nothing in Ghost writes to it afterwards, but nconf doesn't know that. Every config.get() walks all nine stores, and for an object-valued key it collects a hit from each one and deep-merges them - on every single call. There are 353 get call sites in core, some on per-request paths. freeze() makes the instance read-only and memoises get() by key. Because each cached value is whatever nconf itself returned for that key, a frozen lookup can't disagree with an unfrozen one, and with writes rejected a cache entry can't go stale - so there's no invalidation to get wrong. Measured against the real config: get('database') 3526ns -> 15ns, getSiteUrl() 1276ns -> 63ns. The mutators throw rather than no-op. nconf's own readOnly flag would have been the obvious lever, but Provider._execute *skips* read-only stores for a destructive action and returns undefined, which turns a config write into a silent failure instead of a loud one. loadNconf freezes as its last step rather than leaving it to boot, so a write during boot fails loudly instead of quietly working. Nothing in the tree does that today - the last two runtime writes were the asset hash, moved into the asset hash service - so this holds the line rather than changing behaviour. It's skipped under test, where the suites rewrite config between cases on purpose, and optimization.freezeConfig turns it off entirely. A keyless get() is left uncached. nconf's env store holds the whole environment, so the merged tree materialises it - on a boot here, 139 of 194 top-level keys came from env rather than config - and caching that would mean a long-lived object holding every environment variable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude
Failed
30722
c8c3b7b4 Added a freeze helper that makes config read-only after boot no ref Config is fully loaded by the time loadNconf() returns, and nothing in Ghost writes to it once booted, but nconf doesn't know that. Every config.get() walks all nine stores, and for an object-valued key it collects a hit from each one and deep-merges them - on every single call. There are 353 get call sites in core, some on per-request paths. freeze() makes the instance read-only and memoises get() by key. Because each cached value is whatever nconf itself returned for that key, a frozen lookup can't disagree with an unfrozen one, and with writes rejected a cache entry can't go stale - so there's no invalidation to get wrong. Measured against the real config: get('database') 3526ns -> 15ns, getSiteUrl() 1276ns -> 63ns. The mutators throw rather than no-op. nconf's own readOnly flag would have been the obvious lever, but Provider._execute *skips* read-only stores for a destructive action and returns undefined, which turns a config write into a silent failure instead of a loud one. Boot freezes after the app is mounted rather than at load, so anything that still wants to write during startup keeps working and only runtime writes are rejected. It's skipped under test, where the suites rewrite config between cases on purpose, and optimization.freezeConfig turns it off entirely. freeze() also reports shadowed keys. nconf reads the whole environment, so a stray env var can collide with a config namespace, and because lookups resolve per key path the collision only half-applies: storage=/mnt/data ghost run config.get('storage') -> '/mnt/data' config.get('storage:active') -> 'LocalImagesStorage' (still the default) Ghost boots fine in that state today and quietly ignores half of what the operator asked for, so boot now warns about it. This is a diagnostic only - freezing caches what nconf returns, so it changes no lookup's result. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s9ZdgxjVXMr7YTh4UtmtH
by Claude