-
Notifications
You must be signed in to change notification settings - Fork 72k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PayloadTooLargeError: request entity too large #7129
Comments
I saw this, #5704 but am guessing since I tried Dev it either hasn't been implemented everywhere or my issue is slightly different. |
Furthermore I just noticed my Autotune is failing to pick up manual pump basal changes (I recently had to drop the rate in the evening significantly because of frequent lows). This adjustment is not reflected in my loops. I ran Autotune manually and got the following error...
It's hard to tell but it seems like the NS API could be responding incorrectly perhaps?
File is an empty list :( |
The error implies your rig is trying to upload a very large chunk of JSON data in one go and it's overflowing the server. Looks like we can bump up the buffer size for this. The autotune error looks like something else |
I've been doing some support work on a similar issue. It turns out the default request body size set by expess's I see common options for 5Mb - 50Mb. Some clients, such as xdrip, are able to circumvent the limit by gzipping their payloads. I suspect 5mb would be enough and would be happy to put together a PR for this. |
Thanks both for your responses. @bewest I'm happy to test a feature branch when the time comes. |
@old-square-eyes, can you confirm the size of the files in the If you are not sure, you can schedule some time with me to help figure it out. |
@bewest am I in the right dir?
and
|
Yes, perfect, @old-square-eyes. Thanks for the information. Your file is 215K, which is more than the 100K limit being enacted currently. I'm currently testing with a similar file, which contains 30k records in it. My |
@bewest is this ready for me to test? Or is it a work in progress (as wip might suggest) |
@bewest I tried your feature branch and it's been working for 6 hours so far. Thank you my friend! This was a great source of distress and it means a lot for you to have jumped on this. Frankly I have no idea why I seem to be one of only a few with the issue. I have no idea why I had a large upload. The rig in question is a daily driver so shouldn't have gone offline for any length of time necessitating a big upload when returning online. |
I just tried a manual run and Autotune still fails. I am currently using NS tokens. I might switch to API key to see if that resolves the issue. I recall @sulkaharo once put in a patch to allow tokens as secrets, which worked for me... I just thought OpenAPS Dev fixed that. But maybe they didn't. Will report back. Thanks again both. |
Autotune is working again per openaps/oref0#1410 Completely separate issue. |
@old-square-eyes: Thanks for all the feedback on this issue! It's been very helpful. Closing for now, as the patch is included in |
Describe the bug
NS stops displaying treatments. This includes OpenAPS insulin, temp basal rates. Visually this propagates to NSClient also.
ns-looplog on OpenAPS shows the following error - probably a HTML page being served up by the NS API when it shouldn't be...
Looking at Atlas DB, all writes cease, as if NS has locked up. Dropping the treatments collection temporarily fixes things, but the lock up returns.
I have 4 clients. This happens on Master and Dev NS.
The text was updated successfully, but these errors were encountered: