Remix.run Logo
AuthAuth 6 hours ago

It seems like passive is the best option here but can someone explain why one real request must fail? So the load balancer is monitoring for failed requests. If it receives one can it not forward the initial request again?

jayd16 5 hours ago | parent | next [-]

Not every request is idempotent and its not known when or why a request has failed. GETs are ok (in theory) but you can't retry a POST without risk of side effects.

OptionOfT 2 hours ago | parent | next [-]

There were some issues with replaying certain GETs back in the day:

https://news.ycombinator.com/item?id=16964907

bdangubic 3 hours ago | parent | prev [-]

I am a contractor and have been fixing shit large part of my career. non-idempotent POSTs are just about always at the top of the list of shit to fix immediately. To this day (30 years in) I do not understand how can someone design a system where POSTs are not idempotent… I mean I know why, the vast majority of people in our industry are just not good at what they do but still…

SoftTalker 3 hours ago | parent [-]

Yep. I worked in corporate back-office IT way before the web era. It was a requirement that every batch job be re-runable idempotently. So if it failed, you'd identify the bad data, excise it, rerun the job, and deal with the bad record in the morning.

cormacrelf 5 hours ago | parent | prev [-]

For GET /, sure, and some mature load balancers can do this. For POST /upload_video, no. You'd have to store all in-flight requests, either in-memory or on disk, in case you need to replay the entire thing with a different backend. Not a very good tradeoff.