Serialize decision-history updates to prevent lost concurrent entries

[knytcomics-ui]

Category

Intermediate

Summary

Replace the read-then-write history update with a concurrency-safe persistence strategy.

Current Behavior

src/lib/history.ts reads the full array and then writes the updated array. Concurrent decisions can read the same old value and overwrite one another.

Problem

Concurrent signing requests can cause valid decision records to disappear.

Why This Matters

Decision history is a user-facing audit trail and should accurately reflect extension decisions.

Proposed Scope

Serialize writes or use another safe update mechanism, preserve the 200-entry cap, validate stored entries, and define storage-failure behavior.

Acceptance Criteria

• Concurrent appends preserve accepted entries up to the limit.
• Newest-first ordering remains deterministic.
• Malformed values do not crash history loading.
• Storage failures have a controlled error path.
• Tests reproduce concurrent writes without lost entries.

Technical Considerations

Relevant modules: src/lib/history.ts, src/background/background.ts, and src/history/History.tsx.

Testing Requirements

Test concurrent appends, cap enforcement, malformed storage, and rejected storage operations.

Cross-Repository Impact

None identified.

Out of Scope

Cloud synchronization or changing retention policy.

Complexity

Intermediate — asynchronous coordination and UI failure handling.

Impact

High — protects audit-trail integrity.

Suggested Labels

intermediate, enhancement, bug