{"version":"2.1.259","anchor":"config-load-now-distinguishes-parse-errors-from-read-errors","canonical_anchor":"config-load-now-distinguishes-parse-errors-from-read-errors","heading":"Config load now distinguishes parse errors from read errors","tier":"internal","area":"Configuration","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.259\/e\/config-load-now-distinguishes-parse-errors-from-read-errors","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.259","markdown":"### Config load now distinguishes parse errors from read errors\n\nConfig loading now distinguishes read errors from parse errors, and both trigger the fallback-to-cache path.\n\nInternal config-loading state now tracks a `lastGetConfigOutcome` enum with values `\"parsed\"`, `\"parse-error\"`, `\"read-error\"`, and `\"enoent\"`, replacing the previous boolean `lastGetConfigWasParseError`. Callers now branch on both parse-error and read-error cases to trigger fallback-to-cache behavior, where previously only parse errors did, and the outcome is surfaced as a `readRejected` flag alongside the returned config.\n\n- Area: Configuration\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}