Prevent GuildCreate from firing for existing guilds during initial ga…

[GlitchApotamus]

…teway hydration.

Description

Summary

Prevents Events.GuildCreate from being emitted for guilds received as part
of the initial gateway guild stream when waitForGuilds is enabled.

Previously, existing guilds delivered through GUILD_CREATE after an empty
READY.guilds payload were indistinguishable from newly joined guilds at the
event-emission layer, causing GuildCreate listeners to fire on every bot
restart.

Changes

• Treat GUILD_CREATE events received during initial guild hydration as
  startup state rather than new guild joins.
• Reset the guild stream settle timer as initial guilds arrive.
• Preserve GuildCreate for guilds actually joined after the client becomes
  ready.
• Add coverage for startup hydration and real guild joins.

Testing

Verified that:

• Restarting a bot already in a guild does not emit GuildCreate.
• Existing guilds are still hydrated correctly.
• Removing and re-adding the bot emits GuildCreate.
• Multiple startup guilds do not emit false join events.
• Existing test suite passes.

Type of change

• Bug fix
• New feature
• Breaking change
• Documentation update

Checklist

• My code follows the project's style guidelines (run pnpm run lint)
  biome lint .
  Checked 489 files in 96ms. No fixes applied.
• I have run pnpm run build successfully
  Tasks: 11 successful, 11 total
  Cached: 11 cached, 11 total
  Time: 47ms >>> FULL TURBO
• I have run pnpm run test successfully
  Tasks: 20 successful, 20 total
  Cached: 9 cached, 20 total
  Time: 3.934s

AI disclosure

Did you use AI (e.g. Cursor, Copilot, ChatGPT, Claude) to help write or review this PR?

• No — I wrote this myself
• Yes — AI assisted (briefly note how below)
• Yes — AI wrote 60% or more of this code

Diagnosed the problematic code.
Guided me to the files that required the edits.
I updated the code myself after a brief idea was drafted.

[greptile-apps]

Confidence Score: 4/5

The PR is not yet safe to merge because a startup guild stream lasting beyond the fixed timeout can violate the waitForGuilds readiness guarantee.

Findings

1.  Startup Timer Expires Early ▶

Summary

This PR changes guild lifecycle handling to suppress GuildCreate for available snapshots explicitly marked with unavailable: false, while retaining GuildAvailable for recovered guilds and using a timeout to finish empty-READY hydration.

• Removes readiness-state and known-membership classification introduced in the earlier revision.
• Uses the gateway availability field to distinguish snapshots from ordinary guild creation.
• Keeps a 500 ms fallback for an empty initial guild list, but no longer extends it as guilds arrive.
• Adds a patch changeset for @fluxerjs/core.

Diagram

sequenceDiagram
  participant GW as Gateway
  participant C as Client
  participant A as Application
  GW->>C: READY (guilds: [])
  C->>C: Start 500 ms timer
  GW->>C: Existing GUILD_CREATE
  C->>C: Hydrate guild (timer unchanged)
  C->>A: Ready after original 500 ms
  GW->>C: Remaining existing GUILD_CREATE
  C->>C: Hydrate after Ready
  Note over A,C: Ready may expose an incomplete guild cache

Loading

_{Reviews (2) · Last reviewed commit: "rebase: revert all changes; update guild..."}

[GlitchApotamus]

A new update has been pushed to fluxerapp/fluxer:main to return guild availability. I have rebased this PR back to :main branch and made a minor change that should completely fix the bug.

[blstmo]

Will take a look when I get home @GlitchApotamus

[blstmo]

LGTM

[blstmo]

As a note for myself and future PR readers this is not the final form that will be implemented in the Client but I am crediting this user for getting the issue resolved on Fluxer's side.