fix(dav): compare sync token retention against an absolute cutoff

[mooons]

Summary

PruneOutdatedSyncTokensJob computes retention as a duration in seconds from syncTokensRetentionDays, but both DAV backends currently compare that value directly against created_at in pruneOutdatedSyncTokens().

created_at stores Unix timestamps, so this ends up using a relative duration as if it were an absolute timestamp. With the default 60-day retention, the generated condition is effectively created_at <= 5184000, which does not match normal rows.

Fix

Convert the duration into an absolute cutoff inside the backend methods before building the delete query:

$cutoff = max(0, time() - $retention);

and compare created_at against $cutoff.

This preserves the current method signatures and config semantics.

Root cause

The retention value is produced as an age duration in PruneOutdatedSyncTokensJob, but treated as an absolute timestamp in:

• OCA\DAV\CalDAV\CalDavBackend::pruneOutdatedSyncTokens()
• OCA\DAV\CardDAV\CardDavBackend::pruneOutdatedSyncTokens()

Impact

Without this fix, old rows in oc_calendarchanges and oc_addressbookchanges are not pruned as intended even when the background job runs.

Related: #51120

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[ChristophWurst]

I have restored the PR template. Please fill it out.

[ChristophWurst]

Changes make sense

Thanks for the contribution!

[tcitworld]

Logic looks good, but tests say no.

[SebastianKrupinski]

Hi @mooons

Thank you for the contribution!

Could you also fix the failing tests?

There were 2 failures:

1. OCA\DAV\Tests\unit\CalDAV\CalDavBackendTest::testPruneOutdatedSyncTokens
   Failed asserting that 6 is identical to 0.

/home/runner/actions-runner/_work/server/server/apps/dav/tests/unit/CalDAV/CalDavBackendTest.php:1403

2. OCA\DAV\Tests\unit\CardDAV\CardDavBackendTest::testPruneOutdatedSyncTokens
   Failed asserting that 933 is identical to 0.

/home/runner/actions-runner/_work/server/server/apps/dav/tests/unit/CardDAV/CardDavBackendTest.php:880

[mooons]

Hi @mooons

Thank you for the contribution!

Could you also fix the failing tests?

There were 2 failures:

1. OCA\DAV\Tests\unit\CalDAV\CalDavBackendTest::testPruneOutdatedSyncTokens
   Failed asserting that 6 is identical to 0.

/home/runner/actions-runner/_work/server/server/apps/dav/tests/unit/CalDAV/CalDavBackendTest.php:1403

2. OCA\DAV\Tests\unit\CardDAV\CardDavBackendTest::testPruneOutdatedSyncTokens
   Failed asserting that 933 is identical to 0.

/home/runner/actions-runner/_work/server/server/apps/dav/tests/unit/CardDAV/CardDavBackendTest.php:880

Done. I've pushed the test fixes. Thanks for reviewing this!

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)