{"version":"2.1.235","anchor":"history-purge-goes-through-the-storage-backend-with-a-hard","canonical_anchor":"history-purge-goes-through-the-storage-backend-with-a-hard","heading":"History purge goes through the storage backend, with a hard refusal when it cannot","tier":"internal","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235\/e\/history-purge-goes-through-the-storage-backend-with-a-hard","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.235","markdown":"### History purge goes through the storage backend, with a hard refusal when it cannot\n\nHistory purge now goes through the storage backend, with a hard error when it can't rewrite safely\n\nCounting and rewriting `history.jsonl` for a purge now prefer the storage interface, a paged scan followed by `replaceRecords`, falling back to the old readline-based path only when the backend defers. Some conditions now raise a fatal error saying the file was not rewritten instead of failing silently: a symlinked or non-regular history file, or a declined read or rewrite. Purge failure telemetry also became per-code, reporting `multiple_failures` when several codes appear, instead of a single blanket `config_write_failed`.\n\n- Area: Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}