When I upload a large MB file in the case filing submission, the PDF API fails.

[Ramu-kandimalla]

This issue is not related to large file.
The issue occurs when the back end returns wrong MIME type for ex. application/json instead of application/pdf.
The external api used to fetch file based on filestore id.
"/filestore/v1/files/id/....

Currently we can gracefully handle this response failure in the UI by showing an error message by checking the MIME type before Doc viewer internally checks it.

But the root problem lies within the API's response.

[ashishbeehyv]

MIME type should be correctly mapped for the browser to know what type of file it is.
it is mandatory to send correct MIME type in response.
for ex. if the file is pdf and MIME type returned from api response is
Content-Type: application/json instead of
Content-Type: application/pdf
it is an issue, the rendering/downloading the file fails.

[ashishbeehyv]

HI @atulgupta2024, @manimaarans, @harshgupta-pucar, @Ramu-kandimalla, @dharani-beehyv
Did more analysis on this issue and found this:
For storing files MiniO is getting used and it takes time from 100ms upto seconds to store the file.
until that time.
scenario:
Stores metadata in DB -> Returns fileStoreId immediately But uploads to MinIO happen asynchronously

if front end checks: GET /files?fileStoreId=xxxx -> in its reponse backend response with an json with error reponse with application/json mimeType.

the 3rd party component for rendering the doc viewer internally keeps calling the api to fetch the pdf until the required reponse is received as required, but sometimes it does not repeat the api calls -> this is what's causing the issue.

SOLUTION:

we can use polling of some fixed intervals lets say 800 ms and keep calling the api from front end itself until the reponse matches the expectation and stop polling .
once the polling stats we render the image/pdf on UI until that time we show a loader.
In this manner the DocViewer component will not require to call the api internally multiple times because the time delay because of MiniO has passed.

The above solution we can implement from front end side for time being but polling is not permanent solution.

the back end logic needs to be changed to accomodate delay from MiniO.

suggestion for back end to check:

Please add a retry mechanism on the file-fetch API so that the backend only returns the file when MinIO has it, and returns a proper 404 otherwise. Do not return application/json or error payloads as file response.
-> This will also ensure lesser number of requests from front end side. (if we observe currently there are several calls happening from front end side just for file fetching which also slows down the app causing performance issue)

[ashishbeehyv]

Current Issue Observed in Frontend

When a user uploads a file, the upload API (/filestore/v1/files ...) returns a fileStoreId immediately, before the file is fully persisted and available in MinIO.

The frontend has to render the uploaded file in UI so front end uses this fileStoreId to call:

GET /filestore/v1/files/id?fileStoreId=...

and get the file to renderr on screen.

During the first 1–3 seconds after upload, MinIO has not yet completed storing the object.
As a result, the file-fetch API intermittently returns:

400 Bad Request

or an error JSON payload

with Content-Type: application/json instead of the file’s actual MIME type (e.g., application/pdf).

Because the response is not a valid file, the document viewer (DocViewer) tries fallback renderers internally and ends up making multiple GET requests before the file finally becomes available.

This inconsistent API behavior causes unpredictable file preview failures on the frontend.

Recommended Backend Actions

One of the following should be implemented:

Option A — Upload API should only return fileStoreId after MinIO confirms persistence

OR

Option B — File-fetch API should implement internal retry (200–300ms intervals) before returning the response, and only return:

200 OK + correct MIME + file bytes, or

404 Not Found if the file truly does not exist

But never return application/json or temporary MinIO errors.