Sometimes the fix is to delete the thing

I built a participant feedback form for an event platform, where people record a short video at the end of an event. On a venue’s flaky mobile signal, those videos kept failing. The upload would start, climb to a few percent, and then the screen would quietly reset as if nothing had happened.

Four places to fail

The videos were travelling through a long chain before they reached storage: the phone, a content network, one web server, another, the app itself, and finally the file store. That is a lot of hops, and on a weak mobile connection any one of them could drop the upload. The logs showed a failure somewhere in the middle, but most failed attempts never even reached our servers, so there was nothing to see.

I spent real time trying to work out which link was breaking. The honest answer was that I could not tell from the logs, and I did not need to.

Delete the chain

The fix was to stop sending the video through all those servers at all. Modern browsers can upload a file straight to the storage service. That removes every middle hop as a thing that can fail. Once I stopped asking “which server is breaking?” and started asking “why is the video going through these servers in the first place?”, the fix wrote itself.

There is a smaller lesson hiding in here too. When the upload failed, the screen silently reset. People do not file useful bug reports for that. They just try again, fail again, and quietly stop trusting the feature. Adding a visible progress bar and a clear error you can retry from did as much for how reliable the feature feels as the upload fix itself.

A chain of servers is a chain of places to fail. Sometimes the right move is not to tune the chain, but to delete it.