In a nutshell, doing it this way adds robustness when – not if – the destination software changes its behavior, inadvertently or not. It’s very similar to software assertions: if this assumption stops holding, then we want to know ASAP because it means subsequent logic is no longer valid.

In the Immich case, the author writes:

This is a side effect of how Immich checks permissions, not a feature made for this purpose, so a future version of Immich could change it. If this ever changes, the share links will answer 404 and I will notice quickly.

Suppose the author updates their Immich instance but missed a remark in the release notes that share keys will be using a different hash algorithm. That’s a mistake with their upgrade procedure, sure, but it’d be ideal if such mistakes were detected sooner than later. Without the check for link validity, the only log that would record the now-invalid share links would be in Immich logs. But with this additional check, there is also a log at Caddy. More visibility, combined with an existing alerting regime, means errors and mistakes are captured earlier.

At first glance, it might seem like both approaches still result in a 404 for the user, which suggests neither approach is really “robust”. But one is a near-silent failure yet the other gives a loud, unmistakable signal that something is broken, meaning it can be addressed. Phrased another way, the signal-to-noise ratio of an assert fail is very strong.