Help return get<IndexingStatusBatchResponse>(/datasets/${datasetId}/batch/${batchId}/indexing-status, {}) not have

[Yexijian0911]

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.

export const fetchIndexingStatusBatch: Fetcher<IndexingStatusBatchResponse, BatchReq> = ({ datasetId, batchId }) => {
console.log('fetchIndexingStatusBatch', datasetId, batchId)
return get(/datasets/${datasetId}/batch/${batchId}/indexing-status, {})
} url not have in api server ？

2. Additional context or comments

No response

[dosubot[bot]]

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

The endpoint /datasets/${datasetId}/batch/${batchId}/indexing-status was added to the Dify backend in a recent update (PR #25778, merged on 2025-09-16). If you don't see this endpoint on your API server, you may be running an older version of Dify. Upgrading to the latest version should resolve the issue and make this endpoint available.

If upgrading isn't possible, there isn't an alternative endpoint for batch indexing status in previous versions—this functionality was missing until the recent update.

To reply, just mention @dosu.

---

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

[Yexijian0911]

Thank you for your answer, I have a question: why did I use my own local code to deploy to the container server, and the effect of the service call this interface was successful, but it was not successful locally.
/console/api/datasets/33a98081-56d2-46ef-af79-9141577b2216/batch/20250925053904991095/indexing-status net::ERR_CONNECTION_REFUSED

[dosubot[bot]]

This usually happens because your local environment is missing something that the container server has set up correctly. The most common causes are: the backend server isn’t running locally, it’s running on the wrong port, or your .env file has incorrect API URLs (like CONSOLE_API_URL, SERVICE_API_URL, APP_API_URL). Make sure your backend is running and listening on the expected port (often 5001), and check that your environment variables match your setup—these need to be set even for local deployments to avoid connection issues source.

If you’re using Docker, remember that changing NEXT_PUBLIC_API_PREFIX in your .env file requires rebuilding the frontend image; otherwise, the frontend will keep using the old API endpoint baked into the image, which can cause connection refused errors source.

Also, confirm that all required backend services (like the vector database) are running, and there are no firewall rules blocking the port source. If you’ve checked all this and still see the error, look at your backend logs when you make the request—they’ll usually show what’s going wrong. If you need more help, sharing those logs or your config will make it easier to diagnose.

To reply, just mention @dosu.

---

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

[Yexijian0911]

My local service is successfully started and can be called to each other, but only this interface does not exist, and my API background service in the source code does not find the declaration of this interface address?

[dosubot[bot]]

The reason you can't find the /datasets/${datasetId}/batch/${batchId}/indexing-status endpoint in your local API source code is that it was added very recently. It's implemented as the DocumentBatchIndexingStatusApi class in api/controllers/console/datasets/datasets_document.py and registered with the Flask API router in the latest Dify backend code see implementation.

If this class and route are missing in your local code, your codebase is outdated. To fix this, pull the latest main branch from the official Dify repo, rebuild your Docker images or restart your backend services, and run migration commands like flask db upgrade and flask migrate-data-for-plugin inside your API container upgrade instructions.

If you have local customizations or uncommitted changes, resolve any conflicts before updating. After upgrading, if you still have connection or CORS issues, double-check your environment variables (like CONSOLE_API_URL, NEXT_PUBLIC_API_PREFIX, etc.), port configuration, and restart your containers local config tips.

If you need help with specific error logs or configs after updating, feel free to share them!

To reply, just mention @dosu.

---

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