When doing web uploads files get stuck on "upload complete, waiting" even if succeeded

[Fogest]

My files are getting stuck in the status seen in the image below:

I have migrated from paperless-ng I had setup on a previous server to a new one. And everything but the web upload based consumption seems to be working. On my old installation there was no issue with web based uploads. Now I do not understand the what the issue is here. According to the logs (seen in image below), the file is processed without issue. And if I check the website the document does indeed get uploaded properly with OCR and everything. If the file has a different error such as it being a duplicate this still does the same and is stuck with the same message. However again the logs will properly indicate the error. It's almost as if the updated status of the file upload isn't getting back to the browser for some reason.

Did I mess something up with the configuration?

I am using the docker setup with an unchanged docker compose YML file, and only a few basic variables set in the docker compose env file. Nothing different from my old setup there.

[siancu]

I am seeing exactly the same behavior. Where do you run the docker container? I'm running it on a Synology NAS.

If I run paperless-ng locally in a dev environment, then the behavior is correct, i.e. the UI gets updated accordingly.

[Fogest]

I am running it on a Ubuntu 20.04 machine and using docker as well. I'm just wondering if my ssl reverse proxy has anything to do with the problem. Though my old installation was reverse proxied as well and was working.

…

On Tue., Nov. 30, 2021, 4:25 a.m. Stelian Iancu, ***@***.***> wrote: I am seeing exactly the same behavior. Where do you run the docker container? I'm running it on a Synology NAS. If I run paperless-ng locally in a dev environment, then the behavior is correct, i.e. the UI gets updated accordingly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI4C3HB5KYWJGYAVHDB5S3UOSKBRANCNFSM5JAW6F2A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[siancu]

Actually in my case the reverse proxy was breaking it. If I go directly to http://localname.homelab:8100 then it works.

[Fogest]

Interesting, I'll have to check my reverse proxy setup when I get home and compare it to my setup on my old machine. My old machine was reverse proxied as well and didn't have this issue. Though I feel like I recall having a similar problem in the beginning and I can't remember what fixed it. I'll have to see if Apache is throwing any errors or if any errors are sitting in the browser console when I upload.

…

On Tue, Nov 30, 2021 at 10:01 AM Stelian Iancu ***@***.***> wrote: Actually in my case the reverse proxy was breaking it. If I go directly to http://localname.homelab:81000 then it works. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI4C3AV55QMHWJAUOQLL33UOTRNRANCNFSM5JAW6F2A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.