One specific endpoint has a function that takes 2-3 minutes to execute. When I was hitting the endpoint I was getting a timeout error. I asked Claude to fix it, and it came up with a huge change in the front end (polling) and backend (celery) to support asynchronous operations.
I instead increased the nginx timeout from 1 minute to 5 minutes. Problem solved without introducing 100x the complexity.
You are just waiting for this to deteriorate, and at some point that 5min timeout is not long enough, and you'll have to come up with something else again.
And more generally, there are multiple issues with properly handling long running actions -- you want a good UX for these actions in your app, they may need to be queued or be allowed to cancel etc. I don't know the exact situation, but I assume this is a small app so you don't care much about it. But in any serious application where UX is important and you don't want someone to submit 10000 such requests (or 10000 users submitting at the same time) to blow up your backend, the sane design is to do this asynchronously with other mechanism to manage the actions.
No not really. The engineer’s job is work within the constraints first and when a big change is really warranted, pursue it.
It’s having a structural issue that can be fixed with a reinforcement, and an automated system suggests to demolish and rebuild part of the most structure altogether. It’s not that clear cut. You maybe right but I wouldn’t jump into conclusions like this.
Disclaimer: not one of those "you didn't prompt right whenever LLMs fail" people, but just something I've noticed in my use of LLMs - they usually don't have the problem context so can't really tell you "should we even be going down this path"
But I was trying to simulate the vibe coding experience where you are completely clueless and rely exclusively on the LLM. It works, but it creates even more work (we call it debt) for the future.
PS I was using Claude within Copilot, so it could definitely see the docker & nginx configuration.
If what you wanted was a simple ductape quick fix I'm sure you could have asked for that and Claude would have recommended what you did, increasing the timeout window which I guess "fixes" the problem.
What is the risk introduced by a long request that requires you to increase to your code complexity by 100x?
Sure I could also dump completely Django and build from scratch with the provision for 10B concurrent users.
My point is that when coding, business context is needed. I was expecting to see from the model what the root cause was and clear statement of the assumptions used when providing the solution. Instead, what I got was "this is a long request, here is the most likely solution for long requests, enjoy your new 1000 loc and dependencies"
"Business context is needed." Then why don't you provide that context? You expect Claude to read your mind? What are we talking about here?
Dude, be humble. If all you want to do is to argue instead of having a productive discussion, this is not the place for you.
I wonder if this is something you could get Claude to think about by adding some rules about your business context, how it should always prefer the simplest solution no matter what.
Out of curiosity I asked Claude.
“I have an application, it only has a few users, hosted on nginx. There is 1 endpoint which can take up to 5 minutes to execute. What’s the best way to fix this?”
Response:
“Immediate fix…
Increase nginx timeout settings explains how”
I happen to have a php project here hosted on nginx with docker locally for running and testing. So I asked cursor the exact same question. It suggested refactoring to make the call async, or changing nginx. I said change nginx. It updated the config and rebuilt docker compose to make sure the change happened.
It’s always a user issue when it comes to using AI.