Fix shard crash when bot is removed from a server during fleet spawn

[erickang21]

Failure scenario

During the startup spawn window a server owner kicks/removes uwu bot (or an outage makes a guild unavailable and it is pruned). guildDelete fires on an already-ready shard, but the fleet is still spawning, so this.client.shard.broadcastEval(...) — and setActivity() right after it — throw ShardingInProcess. These calls sat outside any try/catch, and with no unhandledRejection handler the shard process dies, temporarily taking the bot offline for every user on that shard.

This is the same class of crash already observed in error.log (repeated uncaught ShardingInProcess exceptions), here triggered by leave events rather than join events.

The change

src/events/guildDelete.js: wrap the log-channel broadcastEval and the follow-up setActivity() call in a try/catch that logs the error and continues, mirroring the existing try/catch around the analytics block just below. A leave event fired mid-spawn now logs a recoverable error instead of crashing the shard; the analytics recording (already guarded) still runs.

While on the touched line, corrected the copy-pasted [GuildCreate] log tag to [GuildDelete] so this exact crash is easier to trace in the logs.

Commits

1. Guard guildDelete broadcast against ShardingInProcess crash — the try/catch wrap plus the log-tag correction.

Testing

The fix touches an event (guild-leave / sharding lifecycle), not a command, so the Discord command harness does not apply. node -c confirms the file parses. npm run lint and npx prettier --check both fail on this repo independently of this change (ESLint v10 requires a flat eslint.config.js the repo does not have; the repo's .prettierrc sets the now-invalid trailingComma: false) — the added code follows the repo's 2-space / no-trailing-comma style regardless.

🤖 Generated with Claude Code

https://claude.ai/code/session_015fmAjXRLY4gNz7LttcaiGh

---

Generated by Claude Code

[erickang21]

Review: has issues (safe to merge, but the premise doesn't hold up)

The diff itself is correct and harmless — no logic error in the try/catch, and the [GuildCreate] → [GuildDelete] log-tag fix on the touched line is a legitimate in-scope cleanup. My concern is with the stated justification, which doesn't survive tracing the code.

The "shard crashes" premise is not supported by the code

The PR says the unguarded broadcastEval/setActivity throw "and with no unhandledRejection handler the shard process dies." But events don't run run() raw — EventStore wires event._run.bind(event), and Event._run (src/structures/Event.js:5-16) already wraps run() in a try/catch:

try {
  await this.run(...args);
} catch (err) {
  if (this.name !== "eventError") this.client.emit("eventError", this, err);
}

So a ShardingInProcess thrown at guildDelete.js:39 was already caught — it never becomes an unhandled rejection. It's then re-emitted as eventError, whose own handler (src/events/eventError.js) calls this.client.shard.broadcastEval(report); during the spawn window that also throws ShardingInProcess, but that second throw is swallowed by _run's recursion guard (this.name !== "eventError" is false). There is confirmed to be no process.on('unhandledRejection'|'uncaughtException') anywhere in src/ or index.js — and it doesn't matter, because nothing escapes _run. I couldn't reproduce a crash path from this code; error.log isn't in the repo so I can't check the traces the PR cites.

What the diff actually does (and this part is worth keeping)

The real, useful effect is behavioral, not crash-prevention: before, a throw at line 39 aborted run() and skipped the analytics/guildRetention block below (lines 44-60), routing instead to a noisy eventError embed report. After, the broadcast failure is caught locally, so the churn/retention analytics still records and it's a quiet log.error line. That's a genuine improvement — but the PR should be reframed as "decouple analytics recording from the log-broadcast failure," not "fix a shard crash."

Other issues

• guildCreate.js:37,40 carries the byte-for-byte identical unguarded broadcastEval + setActivity. Out of scope for this PR, but if the crash were real it would remain there — further evidence the mechanism is the shared _run guard, not a per-event catch.
• Convention (minor, pre-existing): the fix keeps this.client.shard.broadcastEval(...) directly rather than the null-safe broadcast() helper CLAUDE.md recommends. In unsharded dev (npm run dev) this.client.shard is null, so this line throws a TypeError; the new catch now silently swallows it and the log embed just never sends in dev. Mirrors guildCreate, so not a regression — just noting the helper would have been the more idiomatic fix.

Verdict

Not blocking — the change is safe and the analytics-decoupling + log-tag fix are worth having. But the description's core claim (prevents a shard crash from an unhandled rejection) is inaccurate given Event._run, and I'd want the rationale corrected before this becomes the reference example for "how we stopped the ShardingInProcess crashes."

---

Generated by Claude Code