Why doesn't increasing the D-Bus method call timeout always fix reliability issues?

It's tempting to treat an intermittent D-Bus timeout as something a longer timeout value will simply paper over, but a timeout is usually a symptom of something specific going wrong, and stretching it out just delays discovering the real cause while making failures slower to surface.

If the destination service is genuinely deadlocked, as in a synchronous call cycle, no timeout length will help since the reply will never arrive at all; the call will just hang longer before eventually erroring out. If the delay is caused by the destination process being blocked on unrelated slow work, such as disk I/O or another blocking call, a longer timeout might let the call eventually succeed, but it also means the calling application appears frozen or unresponsive for that whole window, which is often worse from a user's perspective than a faster, clearer failure.

A more durable fix usually involves converting the call to asynchronous so the caller doesn't block at all, investigating why the destination is slow to respond in the first place, or adding retry logic with backoff for transient conditions, rather than treating timeout duration as the primary lever.