Providing custom `Tracker.list` timeout about phoenix_pubsub HOT 2 OPEN

The work inside the call itself is minuscule - the main part of obtaining the list is performed by the caller directly. So the only reason for timeouts there would be that the shard server is overloaded and has a very long message queue - in that case crashing callers is a very primitive back-pressure mechanism.

from phoenix_pubsub.

In my use case I am willing to accept the caller timing out and then just saying "there's listeners" as a safe default. The 5 second timeout is longer than I'd want however as the timeout length directly affects time to deliver messages when the system is backed up. The timeout of the tracker for track calls will cause the client to reconnect.

Still looking at why my tracker process is backing up. I have ensured that there are no single large topics and have 8 shards which have pretty evenly distributed reduction count. However, having the ability to customize the timeout would allow me to reduce the maximum duration of message delivery in the worst case scenario of a backed up tracker shard.

from phoenix_pubsub.