Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs update: manual sharding #603

Merged
merged 5 commits into from
May 25, 2024
Merged

Docs update: manual sharding #603

merged 5 commits into from
May 25, 2024

Conversation

jb3
Copy link
Collaborator

@jb3 jb3 commented May 24, 2024

  • Update documentation of manual sharding methods in Nostrum.Shard.Supervisor
  • Create new advanced documentation page showing an example of a reconnection

@jb3 jb3 requested a review from jchristgit May 24, 2024 00:43
@tignear
Copy link
Contributor

tignear commented May 24, 2024

The disconnect/1 function returns a sequence (seq). Since the shard cannot deliver events occurring after this seq, the consumer will not receive those events. Moreover, the gateway will not send events occurring before the seq. Additionally, the session ID will be invalidated upon the first reconnection attempt, making it impossible to resume with the same session ID (though it may be possible by sending requests simultaneously). Consequently, events will not be delivered twice.

And Discord guarantees(I'm not sure if this can be called a guarantee.) that the session can be restarted for a few minutes.

If you simply close the TCP connection or use a different close code, the session will remain active and timeout after a few minutes. This can be useful when you're Resuming the previous session.

https://discord.com/developers/docs/topics/gateway#disconnecting

This should not happen with RESUME events, the only situation we can
have in theory is the gateway losing events if the reconnect fails.

We already market this functionality only to advanced users who should
be aware of the risks and intricacies of reconnection.
@jb3 jb3 force-pushed the jb3/docs/manual-sharding branch 3 times, most recently from d27028c to c7109fa Compare May 24, 2024 16:35
@jb3 jb3 force-pushed the jb3/docs/manual-sharding branch from c7109fa to eb01ac0 Compare May 24, 2024 16:42
This means that any future additions into `guides` will automatically be
built by ExDoc when documentation is generated. There is no longer a
need to add the page and then update the Mix file with the new page.
@jb3 jb3 force-pushed the jb3/docs/manual-sharding branch from eb01ac0 to ebd658b Compare May 24, 2024 17:11
@jchristgit jchristgit self-assigned this May 24, 2024
Copy link
Collaborator

@jchristgit jchristgit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice!

@jchristgit jchristgit merged commit d6b1015 into master May 25, 2024
9 checks passed
@jchristgit
Copy link
Collaborator

Thanks!

@jchristgit jchristgit deleted the jb3/docs/manual-sharding branch May 25, 2024 05:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants