Issue: Document "Last Updated" Timestamp Not Updating Despite Successful API Upload (Indexing/Cache Problem?)Help

[es335ab]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Yes, I'm experiencing an issue when updating a knowledge document in Dify via the API.
I'm using the update-by-file endpoint to upload a new CSV to an existing DOCUMENT_ID. The API responds successfully and the new file appears in the Dify dashboard with the correct file name and size. However, the document's "Last Updated" timestamp in the UI does not update, and the actual content also remains unchanged (still showing the previous version). This issue only recently started to occur; previously, the updates worked as expected.

2. Additional context or comments

• API endpoint: POST /v1/datasets/{DATASET_ID}/documents/{DOCUMENT_ID}/update-by-file
• Observed behavior:
  • File name and size update correctly in the dashboard after upload
  • "Last Updated" timestamp remains at the previous value
  • Content shown in the UI does not update
  • API response is successful (no error), with indexing_status as "waiting" and display_status as "queuing"
• File details: About 850 paragraphs, 226,000 tokens, 520KB
• What I've tried:
  • Waiting for several hours (no change)
  • Uploading smaller files
  • Re-uploading multiple times
  • Clearing browser cache and trying different browsers
• Questions:
  • Has anyone encountered a similar issue?
  • Is this related to internal indexing, caching, or a known bug?
  • Is there a way to force re-indexing or refresh the document?
  • Is deleting and recreating the document with a new DOCUMENT_ID the only workaround?
• Screenshots and API responses can be provided if needed.

Thank you for your help!

[dosubot[bot]]

Hi @es335ab! I'm Dosu and I’m helping the dify team.

This looks like an indexing/background task issue rather than a UI cache problem. The update-by-file endpoint should update the document’s content and “Last Updated” timestamp after the async indexing task completes. If the status stays at “waiting”/“queuing” for hours and the content/timestamp don’t change, it usually means the background indexing worker (Celery) is stalled, unavailable, or a recent backend change introduced a regression. There’s no persistent cache at the API/UI layer for document metadata—updates should be immediate once indexing finishes, unless there’s a backend failure or async task isn’t running as expected (source).

There’s no user-facing “force re-index” or “refresh cache” button. Re-indexing is triggered by state changes (like enabling, disabling, archiving, or unarchiving a document), or by retrying failed/paused documents, but these are handled internally and not exposed as public endpoints (source). A recent batch status update API allows you to enable/disable/archive/unarchive documents, which may trigger re-indexing if the document is in the right state (source). Pause/resume operations were also recently added (source).

If the document is stuck in “waiting”/“queuing” for a long time, check that your background worker is running and healthy. If you have access, try toggling the document’s status (enable/disable/archive/unarchive) via the batch status API to see if it triggers re-indexing. If that doesn’t work, deleting and recreating the document is a known workaround, but ideally shouldn’t be necessary (source).

If you’re running self-hosted, make sure your Celery worker is up and processing tasks. If you’re on a managed instance, this may be a backend bug or infrastructure issue—recent changes to indexing logic could be related (source). If you can, check the logs for errors in the indexing task.

Let me know if you need help checking document status or want more details on using the batch status API.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[es335ab]

Thank you, @dosu!
Your advice was very clear and helpful.
Even after creating a new document, I noticed that the indexing sometimes still points to the previously archived document.
I'll continue monitoring with the API as you suggested.
Really appreciate your support!

[dosubot[bot]]

You're welcome! If you notice indexing referencing an archived document, it's likely due to a backend state transition issue—sometimes async tasks or Redis caching can cause the system to mix up document states, especially after recent changes to indexing and status update logic. If this happens, try using the DocumentDetailApi to check the 'archived' and 'indexing_status' fields for both the new and old documents. You can also use the batch document status update API to explicitly archive/unarchive or enable/disable documents, which may reset the indexing reference. If things still seem stuck, restarting the worker container (with docker compose restart worker) often resolves lingering indexing tasks, and checking for connection issues between the worker and external services (like Ollama) can help as well. If you spot any odd API responses or logs, feel free to share them—I'm happy to help interpret or troubleshoot further! source source

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[es335ab]

@dosu
Thank you for the suggestions!

The API responses all appear normal.
Since I’m using the cloud-hosted (managed) version of Dify, I don’t have access to restart the worker container myself.
Given this limitation, is there anything else I can do on my end to resolve the issue?
Or would this require assistance from the Dify support team or backend engineers?

Thanks again for your help!

[es335ab]

@dosu
How about it?

[dosubot[bot]]

Since you're on the managed/cloud version and don't have backend access, there aren't any user-level actions left to resolve this—toggling document status, recreating documents, and waiting are the main options, and you've already tried them. There’s no documented way for managed users to force re-indexing or refresh document state beyond these steps.

Persistent indexing issues like this typically require backend intervention. Recent backend changes to document indexing and status logic (like batch status updates and session binding fixes) may be related to what you're seeing (PR #18235, PR #21015, PR #9989).

At this point, the best path is to provide Dify support with your document IDs and API responses so they can investigate and resolve it on the backend.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}