Fix shard reconnection issue (#1607)

[igor725]

This should fix the old shard is not being there if something in network stack has failed during the reconnection stage. Additionally I removed what looks to be a pair of duplicate parameters with unnecessary std::string copying in the reconnect for client constructor, since old is being deleted long after new discord_client being constructed, it shouldn't be a problem.

Here's traces from my reconnect test:

[2026-07-07 18:06:44] TRACE: Shard 0 not ready to reconnect yet.
[2026-07-07 18:06:44] TRACE: Shard 0 not ready to reconnect yet.
[2026-07-07 18:06:44] TRACE: Shard 0 not ready to reconnect yet.
[2026-07-07 18:06:44] TRACE: Shard 0 not ready to reconnect yet.
[2026-07-07 18:06:45] INFO: Reconnecting shard 0
[2026-07-07 18:06:45] TRACE: Attempting resume...
[2026-07-07 18:06:45] TRACE: Running new connection...
[2026-07-07 18:06:45] TRACE: Deleting old connection...
[2026-07-07 18:06:45] TRACE: Installing new connection...

It's not the actual DNS failure test because it's kinda hard to catch the thing in action, but at least I proved that reconnection mechanism is not broken, my bot still keeps replying to messages after the reconnection.

Code change checklist

• I have ensured that all methods and functions are fully documented using doxygen style comments.
• My code follows the coding style guide.
• I tested that my change works before raising the PR.
• I have ensured that I did not break any existing API calls.
• I have not built my pull request using AI, a static analysis tool or similar without any human oversight.

Documentation change checklist

• My documentation changes follow the docs style guide and any code examples follow the coding style guide.
• I tested that my change works before raising the PR (via running doxygen, and testing examples).
• I have not moved any existing pages or changed any existing URLs without strong justification as to why.
• I have not generated content using AI or a desktop utility such as grammarly.

[netlify]

✅ Deploy Preview for dpp-dev ready!

Name	Link
🔨 Latest commit	d258f53
🔍 Latest deploy log	https://app.netlify.com/projects/dpp-dev/deploys/6a537e8f680d6c0008cd27ca
😎 Deploy Preview	https://deploy-preview-1608--dpp-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[CLAassistant]

All committers have signed the CLA.

[braindigitalis]

there are conflicts in this that have to be resolved.

[braindigitalis]

thanks so much for the pr by the way looking forward to merging it!

[igor725]

I'll look into those conflicts in a bit!

[igor725]

thanks so much for the pr by the way looking forward to merging it!

Glad I could help😁

[igor725]

Adjusted it for smart pointers, should be fine now

[igor725]

Just caught that exception again and realised I forgot to move an old object back to shards list in case of said exception. It did the full recreation so technically it worked but now it should be able to resume, too.

[igor725]

Actually now that I think about it more and looking at discordclient.cpp, the old shard can be sabotaged by new constructor since it's moving that connecting_voice_channels map from old object to a new one. We should either come up with mechanism that brings those channels back in case they were already moved and got their ownership swapped or leave it as is and just do full reconnection on exception

[braindigitalis]

Actually now that I think about it more and looking at discordclient.cpp, the old shard can be sabotaged by new constructor since it's moving that connecting_voice_channels map from old object to a new one. We should either come up with mechanism that brings those channels back in case they were already moved and got their ownership swapped or leave it as is and just do full reconnection on exception

this is already solved by another pr #1606

[igor725]

Actually now that I think about it more and looking at discordclient.cpp, the old shard can be sabotaged by new constructor since it's moving that connecting_voice_channels map from old object to a new one. We should either come up with mechanism that brings those channels back in case they were already moved and got their ownership swapped or leave it as is and just do full reconnection on exception

this is already solved by another pr #1606

Oh, I missed it. Just checked and I think my changes should be fine as is if git merge won't mess logic up.