TLDR: I'd like to make resume_url configurable and expose it's value the same way it's done with session.
I currently try to have my Discord bot reconnect to the gateway after restarting.
There already is partial support for this through setting the Session in the Config. But without the correct resume_url this is unreliable. resume_url is already tracked internally for automatically resuming the shard but there seems to be no way to set one when creating the Shard. So I'd propose making the initial value for this configurable through Config just like session. Also it would be nice if the current resume_url is exposed on the Shard (although it's possible to track this by looking at the Ready events, it seems unnecessary to do this work twice).
I think reconnecting to the correct url is already possible by abusing the proxy url setting, although this probably causes problems if resume at some point fails, because it would try to connect to the old resume url instead of the general api endpoint. Accomplishing that in a less hacky way and without influencing future normal reconnects that don't resume seems to be the better way to do this.
TLDR: I'd like to make resume_url configurable and expose it's value the same way it's done with session.
I currently try to have my Discord bot reconnect to the gateway after restarting. There already is partial support for this through setting the Session in the Config. But without the correct resume_url this is unreliable. resume_url is already tracked internally for automatically resuming the shard but there seems to be no way to set one when creating the Shard. So I'd propose making the initial value for this configurable through Config just like session. Also it would be nice if the current resume_url is exposed on the Shard (although it's possible to track this by looking at the Ready events, it seems unnecessary to do this work twice).
I think reconnecting to the correct url is already possible by abusing the proxy url setting, although this probably causes problems if resume at some point fails, because it would try to connect to the old resume url instead of the general api endpoint. Accomplishing that in a less hacky way and without influencing future normal reconnects that don't resume seems to be the better way to do this.