Feedback on “Unable to process request, please try again” errors

Hi –

I am a new pods user and encountered a 19-field limit with pods which was quite perplexing. The error (of course?!) was: Error: Unable to process request, please try again

…when trying to save the pod with a field count > 19. Anyway, after searching and finding that this issue has been reported a number of times in the past without much success in a clear resolution, other than pointing at the environment — for example: https://github.com/pods-framework/pods/issues/5051

…I tried to dig a little bit deeper. In my case, the failure point was because of httpd/mod_security and the request body limit of 131072 / failure – denied with code 413. So, I doubled the body limits in the mod_security config and it immediately fixed the problem. After that, I was able to save the pod that had been failing at the field limit. It was not a plugin problem, a session save_path problem or WP memory limit issue.

I don’t have a question. I just wanted to offer that if this issue comes up again, ask the user to check the settings in mod_security, since the sizes are too small to function properly with modern wordpress. Also, if you are looking for the reproducible case, it likely involves the following:
1. enable mod_security in httpd
2. set the variables shown below to their default values
3. create a pod that has a large number of fields and keep trying to save it until it fails.
4. adjust mod_security and see if it fixes the problem

For reference:
WordPress Version: 5.4.2
PHP Version: 7.3.8
MySQL Version: 5.5.5
Server Software: Apache 2.4.41 (Fedora/Linux)

Error:
[Wed Jul 01 01:58:31.126405 2020] [:error] [pid 19821:tid 140677795002112] [client xxxx] [client xxx] ModSecurity: Request body no files data length is larger than the configured limit (131072).. Deny with code (413) [hostname “xxx”] [uri “/wp-admin/admin-ajax.php”] [unique_id “XvxQN0HStZX5OzdqMI-3wQAAAMw”], referer: xxx/wp-admin/admin.php?page=pods&action=edit&id=359

/etc/httpd/conf.d/mod_security.conf excerpt:
# SecRequestBodyLimit 13107200 — too small, increased by 2x
SecRequestBodyLimit 26214400
# SecRequestBodyNoFilesLimit 131072 — too small, increased by 2x — this was the one that failed
SecRequestBodyNoFilesLimit 262144
# SecRequestBodyInMemoryLimit 131072 — too small, increased by 2x
SecRequestBodyInMemoryLimit 262144

FIXED!
If it happens again, I will increase it more, but it seems to work as is now. And, to that, I say, enough of this @#%@!$ problem! Hopefully all my wasted time will not be someone else’s if they see this post. And, maybe it will de-mystify the gremlins! ^_^