Browser Console Retention Requirements

Overview

Kandev keeps bounded browser diagnostics for explicit support bundles. Logging must remain off the application-critical path. Retention work must not consume large amounts of CPU when the store is already within its limits.

Terminology

Committed batch: One group of staged entries that IndexedDB accepts in a successful write transaction.
Retained history: All browser log entries across identity partitions in one browser profile.

Requirements

REQ-PLATFORM-BROWSER-CONSOLE-RETENTION-001: Bounded incremental retention

Intent: Preserve exact diagnostic limits without scanning the complete retained history after every log batch.

Acceptance criteria

AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.1: After each committed batch, retained history shall contain no entry older than three days, no more than 10,000 entries, and no more than 20 MiB of serialized entry data.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.2: When entries exceed a limit, retention shall remove expired entries first and shall then remove the oldest entries until all limits hold.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.3: When multiple tabs write to the same browser profile, every committed transaction shall preserve the shared count and byte limits.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.4: After retention totals are initialized, a batch that is within all limits shall not scan unexpired retained entries.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.5: When log batches arrive while persistence is active in one tab, that tab shall run no more than one browser log write at a time.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.6: A console call shall not wait for IndexedDB work. If persistence fails, the bounded memory fallback and diagnostic loss metadata shall remain available.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.7: Clearing browser diagnostic history shall also reset its retained count and byte totals.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.8: Entries emitted during one 250 ms collection window shall use the fewest committed batches allowed by the 50-entry and 256 KiB batch limits. Browser idle time shall not shorten that collection window.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.9: When an explicit diagnostic snapshot starts, it shall bypass the collection window and freeze the current staged entries as its capture watermark. Entries staged later shall not delay that capture.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.10: An explicit diagnostic capture shall enumerate the requested identity partition in chronological batches bounded by the upload target. Each batch shall become available before the capture enumerates or serializes the remainder of the partition. The frontend shall establish the persisted upper boundary at notification receipt before it flushes the receipt prefix. Entries committed after notification receipt shall not appear in any batch. If the frontend cannot prove this boundary, it shall use the bounded memory snapshot for the capture.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.11: A capture shall wait no more than one second for the serialized drain to persist its capture watermark. When this wait expires, the capture shall use its bounded memory snapshot and shall not stop normal persistence.
AC-PLATFORM-BROWSER-CONSOLE-RETENTION-001.12: A browser wall-clock offset shall not change the frontend capture budget. When this budget expires, the frontend shall stop new snapshot reads and uploads. It shall cancel an active upload.

Compatibility and persistence

The existing database name and schema version remain unchanged.
Entries remain partitioned by the authenticated Kandev identity.
Each entry remains limited to 64 KiB.
A diagnostic snapshot returns only the requested identity partition.

Out of scope

Changing bundle upload limits or permissions.
Uploading browser logs continuously.
Adding user-configurable retention limits.
Changing the 500-entry memory fallback or the staging byte limit.

4.2 KiB Raw Blame History