[Watch + Up Next] Clear replaces properly when performing a login sync

[bjtitus]

📘 Part of: Watch + Up Next Sync

The clearPendingUpNextChangesOnLogin Feature Flag controls this change.

The core bug here is that we were calling clearSyncedData(latestActionTime: latestActionTime) where latestActionTime could be 0 (its default value) after syncing during a login, effectively a no-op.

The theory is the following:

1. Device is logged out in the background. The logout doesn't actually clear any of the replace changes, I think the intent here is that another account could be logged in and send replace events to the wrong account.
2. Device is logged back in after reauth with token or manually
3. Sync is triggered
4. The UpNextSyncTask makes a call to clearSyncedData but with the default latestActionTime of 0, this leaves unsynced replace changes.
5. On the next sync after initial login, those replace changes would be sent.

Several of the watch logs indicate logouts which could potentially be more likely to trigger a case like this.

To test

Checklist

• I have considered if this change warrants user-facing release notes and have added them to CHANGELOG.md if necessary.
• I have considered adding unit tests for my changes.
• I have updated (or requested that someone edit) the spreadsheet to reflect any new or changed analytics.

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[Copilot]

Pull request overview

This PR fixes a bug where stale Up Next replace actions persist through login sync and are incorrectly sent on subsequent syncs, potentially clearing the server's queue unexpectedly.

Changes:

• Added feature flag clearPendingUpNextChangesOnLogin (defaulted to false for gradual rollout)
• Modified UpNextSyncTask.process() to clear all pending changes using Int64.max during login sync when feature flag is enabled
• Added comprehensive test coverage in UpNextSyncTaskTests to verify the fix works and doesn't break existing behavior
• Added unit tests in UpNextChangesDataManagerTests to demonstrate the bug at the database layer

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
Modules/Server/Sources/PocketCastsServer/Public/Sync/UpNextSyncTask.swift	Implements the fix: uses Int64.max instead of latestActionTime (which is 0) during login sync to clear all pending changes when feature flag is enabled
Modules/Server/Tests/PocketCastsServerTests/UpNextSyncTaskTests.swift	New test file with comprehensive integration tests verifying the fix works, the bug exists when disabled, and normal sync behavior is preserved
Modules/DataModel/Tests/PocketCastsDataModelTests/UpNextChangesDataManagerTests.swift	Adds unit tests demonstrating the bug at the database layer and verifying the fix approach

[Copilot]

The GitHub issue URL contains a placeholder "XXXX" instead of an actual issue number. This should be replaced with the real issue number before merging.

Suggested change

	// and any pending changes are stale. See: https://github.com/Automattic/pocket-casts-ios/issues/XXXX
	// and any pending changes are stale after applying the latest server state.

[pocketcasts]

Version 8.7 has now entered code-freeze, so the milestone of this PR has been updated to 8.8.

[pocketcasts]

Version 8.8 has now entered code-freeze, so the milestone of this PR has been updated to 8.9.

[pocketcasts]

Version 8.9 has now entered code-freeze, so the milestone of this PR has been updated to 8.10.