WOPI timestamp comparison uses stale modification time causing false DOC_CHANGED conflicts

[demirkaric]

Describe the bug

During collaborative editing of an ODS document with multiple users, Collabora repeatedly displays:

Document has been changed in storage. What would you like to do with your unsaved changes?

Although the document is only being edited through Collabora and nobody modifies it outside the active WOPI session.

After investigating the source code, I traced the conflict to the following code in richdocuments:

if (!empty($wopiHeaderTime) && $wopiHeaderTime !== Helper::toISO8601($file->getMTime() ?? 0)) {
    return new JSONResponse(
        ['COOLStatusCode' => self::COOL_STATUS_DOC_CHANGED],
        Http::STATUS_CONFLICT
    );
}

The comparison fails because the modification time used during the comparison is older than the actual modification time of the file on disk.

Executing:

occ files:scan --path="<path>"

immediately updates oc_filecache.mtime, and after that the WOPI conflicts disappear.

During debugging I compared the filesystem timestamp with the metadata stored in oc_filecache.

Filesystem:

Modify: 2026-06-05 06:43:04 UTC

oc_filecache:

mtime: 2026-06-05 06:38:15 UTC

Running occ files:scan immediately synchronized oc_filecache.mtime with the filesystem timestamp and the conflicts stopped occurring.

This appears to indicate that stale metadata is being used during the WOPI timestamp comparison.

The issue has also been observed on previous Nextcloud versions before upgrading to 33.0.5.1.

---

To Reproduce

1. Install Nextcloud and Collabora Online on separate servers.

2. Use local filesystem storage.

3. Share a large ODS document between several users.

4. Let multiple users edit the document simultaneously for some time.

5. Eventually one or more users receive:

   Document has been changed in storage.

6. Nextcloud responds with HTTP 409 Conflict and COOLStatusCode=DOC_CHANGED.

---

Expected behavior

The WOPI timestamp comparison should not fail when the file has only been modified through the current collaborative editing session.

The metadata used for the timestamp comparison should always reflect the current state of the stored file.

---

Screenshots

---

Client details:

• OS: Windows 11
• Browser: Google Chrome
• Browser Version: 138.0.7204.101 (64-bit)
• Device: Desktop

---

Server details

Operating system:

Ubuntu Server 24.04 LTS

Web server:

Apache

Database:

MariaDB 11.x

PHP version:

PHP 8.3 (Plesk)

Nextcloud version:

33.0.5.1

Version of the richdocuments app

10.2.0

Version of Collabora Online

CODE 25.04.9.5

Storage backend

Local filesystem (no SMB, NFS or External Storage)

Time synchronization

Both Nextcloud and Collabora servers use NTP and have synchronized system clocks.

Configuration of the richdocuments app

"apps": {
    "richdocuments": {
        "canonical_webroot": "",
        "disable_certificate_verification": "yes",
        "doc_format": "ooxml",
        "enabled": "yes",
        "installed_version": "10.2.0",
        "public_wopi_url": "https://xxxxxxxx",
        "types": "filesystem,prevent_group_restriction",
        "wopi_allowlist": "172.16.20.0/24",
        "wopi_callback_url": "",
        "wopi_url": "https://xxxxxxxx"
    }
}

Logs

Nextcloud log (data/nextcloud.log)

Document timestamp mismatch !
WOPI client says mtime 2026-06-05T06:30:49.000000Z
storage says 2026-06-05T06:26:07.000000Z

WOPI timestamp conflict details

fileId: 8217800
path: /user/files/Test/Test.ods
wopiHeaderTime: 2026-06-05T06:30:49.000000Z
storageTimeIso: 2026-06-05T06:26:07.000000Z

Browser log

No JavaScript errors were observed in the browser console.

The browser network trace shows that the PUT request to the WOPI endpoint returns:

HTTP 409 Conflict

Response:
{
    "COOLStatusCode": DOC_CHANGED
}

This results in the "Document has been changed in storage" dialog being displayed by Collabora.

Question

Is it expected that occ files:scan immediately synchronizes the metadata used for the WOPI timestamp comparison?

If so, should the metadata be refreshed automatically after successful WOPI saves to avoid false DOC_CHANGED conflicts?

[pedropintosilva]

Thanks @demirkaric !
this is related to #5794. @elzody this could be it^!