Skip to content

Clean WordPress API cache during account and site removal - #25864

Open
crazytonyli wants to merge 3 commits into
trunkfrom
task/wp-api-cache-single-bootstrap
Open

Clean WordPress API cache during account and site removal #25864
crazytonyli wants to merge 3 commits into
trunkfrom
task/wp-api-cache-single-bootstrap

Conversation

@crazytonyli

Copy link
Copy Markdown
Contributor

Note

This is an alternative of #25853. I recommend reviewing this PR commit by commit.

Description

The main changes is in WordPressApiCache.

Every WordPressClient opened its own WordPressApiCache against the same app.sqlite and re-ran migrations. This PR makes the cache a single process-wide instance and to avoid unnecessary migration runs, which matches the Android app's singleton cache.

The main changes:

  1. Bootstrapping the on-disk cache is now recovery-safe and testable. Opening the database is modeled as an OnDiskCacheOutcome (opened, recovered, or failed) carrying a typed failure.
  2. All clients share one WordPressApiCache.shared instead of bootstrapping per client, so the database is opened and migrated once per process.
  3. Removing an account or site now clears that site's cached data.

Delete SQLite sibling files together with the database, clean up orphaned journal files before creating a new database, and model the result of opening the on-disk cache as an OnDiskCacheOutcome (opened, recovered, or failed) carrying a typed OnDiskCacheFailure. bootstrap() reports failures (each kind from its own call site so wpAssertionFailure's file/line-based analytics identity and suppression stay per-kind) and falls back to the in-memory cache, while the pure worker lets unit tests drive the recovery path without tripping assertionFailure in Debug. A failure to remove a sibling next to a fresh database is itself a corruption vector, so it fails rather than reopening against a stale journal.
Per-client cache instances each opened a connection to the same app.sqlite and re-ran migrations with BEGIN EXCLUSIVE, so concurrent bootstraps could fail with SQLITE_BUSY and delete a database other connections still had open (Sentry JETPACK-IOS-1KCJ). A process-wide shared instance bootstraps once, matching the Android app's singleton cache. Test helpers that built a service from bootstrap() now use the shared instance since bootstrap() is private.
Removing an account or site left its cached API data in app.sqlite, so a
later re-add could read stale entries. Delete the cached data for each
affected site during removal.

The cleanup runs on the process-wide WordPressApiCache.shared instance
rather than opening a separate connection to the database. A second
connection would reintroduce the bootstrap contention this branch
eliminates and would not notify the shared instance's update listeners,
since SQLite update hooks fire only for writes on their own connection.
@crazytonyli crazytonyli added this to the 27.2 milestone Aug 4, 2026
@crazytonyli
crazytonyli requested a review from jkmassel August 4, 2026 04:10
@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
App NameWordPress
ConfigurationRelease-Alpha
Build Number33589
VersionPR #25864
Bundle IDorg.wordpress.alpha
Commitb0d3966
Installation URL5o4guceqaht8g
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
App NameJetpack
ConfigurationRelease-Alpha
Build Number33589
VersionPR #25864
Bundle IDcom.jetpack.alpha
Commitb0d3966
Installation URL0kfb3p9qpdl70
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants