How a Pull Runs
What happens after you start a RestoreCord member pull: setup checks, queueing, preparing the destination server, pacing, Discord rate limits and how it ends.
After you click Pull Members, RestoreCord checks your setup, builds the member list, waits its turn, prepares the destination server, then adds members one at a time until it reaches your pull amount or runs out of members. This page explains each stage so you can predict how long a pull takes and what it changes.
The Stages
Checks before starting
RestoreCord checks that the bot token works, the bot is in the destination server, and invites are enabled there. It also confirms the bot can assign the selected role. If any check fails, nothing starts and you see an error. See start errors.
Building the member list
Eligible members are collected (see eligibility), and each gets a place in the queue. The migration is created as Pending, or Queued if another migration is running for the same server.
Waiting its turn
Only one migration pulls at a time per RestoreCord server. A new migration waits while another one for the same server is pulling, and behind older migrations that are still waiting. A scheduled migration waits until its start time. Migrations for different servers run side by side.
Preparing the destination
The bot sets the destination server's Default Notification Settings to Only @mentions, so a flood of joins doesn't notify everyone. This is skipped if the bot isn't allowed to change it.
It then reads the destination's member list (the Migrations page shows Fetching members for…) and removes everyone who is already there from the queue (Preparing members for…). This needs Server Members Intent. Without it, this step is skipped and those members are found one by one during the pull instead, which is slower.
Pulling
Members are added one at a time, in queue order, with your delay between them. Progress on the Migrations page updates every few seconds.
Finishing
The migration ends as Finished, Stopped or Failed. If Leave server after migration is on and the pull amount was reached, the bot leaves the destination server.
What Happens for Each Member
- Authorization check. RestoreCord checks that the member still authorizes your bot. If Discord refuses, the member is marked as no longer authorized and counted under Members Unauthorized.
- Add to server. RestoreCord asks Discord to add the member to the destination server, with the selected role and nickname.
- Result. Discord's answer decides what's counted: pulled, already in the server, banned, at the server limit, unauthorized or failed. See results.
Members already in the server
Members can turn out to be in the destination server already in two ways:
| How RestoreCord finds out | Role on join | Nickname |
|---|---|---|
| During preparation, from the member list (Server Members Intent on) | Not given | Not set |
| During the pull, from Discord's reply (Server Members Intent off, or the member joined after preparation) | Given | Not set |
Either way, they're counted under Members in Server and don't count towards the pull amount.
Pacing and Rate Limits
- One member at a time. Each migration adds members one after another, never several at once.
- Your delay. Each member waits your fixed delay, or a time within your delay range, measured from the start of the previous request. The first member goes straight away.
- Default delay. If you start a pull through the API without a delay, RestoreCord uses a safe default within Discord's rate limits.
- Groups. With Grouping, the pause between groups starts from the last member of the previous group.
- Discord rate limits. When Discord says to slow down, the whole migration waits as long as Discord asks, then carries on with the same member.
- Temporary errors (Discord outages, timeouts, network errors) are retried automatically.
A migration that seems slower than its estimate is usually waiting on Discord rate limits. Two migrations for different RestoreCord servers that use the same bot share that bot's Discord limits.
How the Pull Amount Works
Every eligible member is queued, not just the number you asked for. RestoreCord works down the queue until the number of members successfully pulled reaches your pull amount, then ends the migration as Finished. Members already in the server, and members who fail, don't count, so a migration can try more members than the amount you set.
When a Migration Ends
| Status | When |
|---|---|
| Finished | The pull amount was reached, or every queued member was tried. |
| Stopped | You stopped it. Members that weren't tried yet are dropped. |
| Failed | Something stopped the whole migration (see below). |
A migration fails as a whole when:
- The bot token stops working, for example because it was reset.
- The bot's client secret changed, so member authorizations can't be refreshed.
- Discord blocks new members from joining the destination server through invites.
- The bot is missing permissions in the destination and keeps getting permission errors. Give the bot's role Create Instant Invite, then start a new migration.
- The bot can't prepare the destination server: Discord rejects the notification-settings change, or the member list can't be read.
- The migration keeps being interrupted by an internal error.
If your bot is removed from the destination server during a pull, the remaining members fail. The activity graph marks the moment with Bot Left. Invite the bot back and start a new pull.
Recovery from Interruptions
RestoreCord saves progress as it goes. If a pull is interrupted, the migration picks up from the members it hadn't finished.
Leave Server After Migration
With Leave server after migration on, the bot leaves the destination server once the migration is Finished and the pull amount was reached. Pulled members stay in the server. RestoreCord never kicks members as part of a migration.
What Is Kept Afterwards
- The migration, its counters and its status stay in your History.
- The queue of individual members is deleted when the migration ends. Only the totals remain.
- Detailed activity (the Migration Activity graph and the record of who left after being pulled) is kept for 30 days after the migration was last updated.