Not really a bug, more clarification

We use a little file upload server that is a simple rack application and uses Puma as the server. I upgraded it from 4.3.3 to 5.2.2 and now we see timeouts after 30 seconds (first_data_timeout) when uploading files to it where the upload takes longer than 30 seconds. I can increase first_data_timeout and the timeout happens at the appropriate time.

An example using curl of an upload is pretty simple curl --data-binary @file.zip server:5000/upload?some=params

The application runs in our Kubernetes cluster behind Traefik which sits behind an AWS ALB/WAF. All that doesn't seem to matter though as using port-forward to talk directly to the pod gives the same result.

Looking in some code it looks like first_data_timeout is deprecated in v6? Or is that just the attr_writer for it?

Just wanting some guidance as to what I should be looking at to solve this problem. I could just revert back to 4.3.3 (which I'll probably do for now), but I'd like to keep upgrading and running the newer version for security, performance, etc., reasons.

I'm slightly confused as to why it's happening in the first place, since I don't know where the data is buffering for it to be waiting and causing puma to timeout. Or is the name first_data_timeout just not accurate in this case and it is getting data, but it's timing out for another reason?

Do I need some other puma configuration? Should I be running nginx in a sidebar to sit in front of puma?

Puma config

workers 1
threads 1, 16

preload_app!

rackup      DefaultRackup
port        5000
environment 'production'