[ruibaby]

Summary

Simplify the RSS SQLite storage lifecycle by removing automatic snapshots,
startup consistency scans, snapshot restoration, and corruption-triggered
database replacement.

Motivation

1. SQLite is more resilient than the previous lifecycle assumed.

   SQLite already provides transaction and crash-recovery guarantees. The
   existing WAL journal mode and synchronous=FULL configuration provide a
   sound durability baseline. Maintaining an additional backup and recovery
   subsystem adds complexity beyond what normal database operation requires.

2. Independent scheduled backups can interfere with Halo's backups.

   The plugin's snapshot creation and rotation can overlap with Halo's own
   backup tasks, introducing competing I/O and changes to files being backed
   up. Removing the separate schedule reduces coordination problems between
   the plugin and the host application.

3. Automatic restoration does not match user expectations.

   A database error should not implicitly authorize rolling data back to an
   older snapshot or replacing it with an empty database. These actions can
   unexpectedly discard reading progress, favorites, and other saved state.
   Preserving the existing files and reporting the failure leaves recovery
   decisions with the user.

4. Halo's built-in backup workflow should be authoritative.

   Users should manage backups and restoration through Halo's built-in
   functionality. The plugin should not maintain a separate backup schedule,
   retention policy, or automatic restoration policy.

Behavior changes

• Open the active SQLite database directly at startup.
• Preserve existing database files and log failures when storage cannot
  start. RSS storage becomes unavailable while link management remains usable.
• Keep WAL, synchronous=FULL, the busy timeout, transactions, and connection
  cleanup.
• Retain one-time Nitrite migration, but never overwrite an existing SQLite
  database with legacy data.
• Leave old snapshots and recovery files untouched for users to manage.
• Update lifecycle tests and the RSS storage specification.

Validation

• 448 backend tests passed, including 60 SQLite tests.
• Regression coverage verifies that corrupt databases are preserved, old
  snapshots are not restored automatically, and manual restoration works.
• Gradle build and plugin reload passed.
• Local Halo smoke checks returned HTTP 200 for RSS items, RSS item summaries,
  and link queries.
• git diff --check passed.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-17T10:32:59.020589Z	636f0ac	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 636f0acdc7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".