Gateway Close: handle deleted-user edge-case without throwing

[devin-ai-integration]

Scope

• Ensure presence updates on disconnect work even if the user was deleted mid-connection
• Fallback to user ID payload when loading full user fails

Acceptance criteria

• Close handler fetches public user reliably or falls back to { id } without throwing
• Presence and session replacement events still emit successfully

Code references

• https://github.com/erkinalp/anticensor/blob/master/src/gateway/events/Close.ts#L92-L99

[traycerai]

Plan

Observations

I analyzed the GitHub issue and the codebase to understand the problem. The issue is in the Close.ts gateway event handler where it tries to fetch a public user for presence updates when a WebSocket connection closes. The current implementation has a try-catch around User.getPublicUser() that falls back to { id: this.user_id }, but this fallback object doesn't match the expected PublicUser structure.

Looking at the PublicUserEnum (lines 39-54 in User.ts), a PublicUser should have fields like username, discriminator, id, public_flags, avatar, etc. The current fallback only provides id, which could cause issues downstream when the presence update event is processed.

The User.getPublicUser() method uses findOneOrFail() which throws when a user is deleted, but the presence update system still needs to work even if the user was deleted mid-connection.

Approach

I'll improve the error handling in the Close.ts file to create a more robust fallback mechanism:

1. Enhanced Fallback Object: Instead of just { id: this.user_id }, create a minimal but complete PublicUser object with all required fields set to sensible defaults
2. Improved Error Handling: Make the catch block more specific and add logging for debugging
3. Consistent Structure: Ensure the fallback user object matches the PublicUser interface structure to prevent downstream errors

The solution will maintain backward compatibility while ensuring presence updates and session replacement events work reliably even when users are deleted.

Reasoning

I started by examining the specific file mentioned in the GitHub issue (src/gateway/events/Close.ts) and found the problematic code around lines 92-99. I then explored the codebase to understand the User.getPublicUser() method, the PublicUser interface structure, and how presence updates work. I analyzed the PublicUserEnum to understand what fields are required for a proper public user object and identified that the current fallback { id: this.user_id } is insufficient.

Proposed File Changes

📄 src/gateway/events/Close.ts ^(MODIFY) 🔗

References

• 📄 src/util/entities/User.ts
• 📄 src/util/interfaces/Presence.ts

I'll improve the error handling for the deleted-user edge case by:

1. Creating a proper fallback user object: Replace the current { id: this.user_id } fallback with a complete minimal PublicUser object that includes all required fields from PublicUserEnum with sensible defaults

2. Enhanced error handling: Make the catch block more specific and add console logging to help with debugging when this edge case occurs

3. Ensuring type safety: The fallback object will match the expected PublicUser structure to prevent downstream errors in presence update processing

The changes will be made around lines 92-99 where the current TODO comment and basic fallback exist. I'll replace the current implementation with a more robust solution that creates a minimal but complete user object with:

• id: the actual user ID
• username: a placeholder indicating deleted user
• discriminator: a default value
• avatar, banner, bio: null values
• bot: false
• public_flags: 0
• Other optional fields: appropriate defaults

This ensures that even when a user is deleted, the presence update and session replacement events can still be emitted successfully without throwing errors.

Diagram

sequenceDiagram
    participant WS as WebSocket Connection
    participant Close as Close Handler
    participant User as User.getPublicUser()
    participant DB as Database
    participant Events as Event System

    WS->>Close: Connection closes
    Close->>Close: Clean up sessions & voice state
    
    alt User exists in database
        Close->>User: getPublicUser(user_id)
        User->>DB: findOneOrFail(user_id)
        DB-->>User: User data
        User-->>Close: PublicUser object
        Close->>Events: Emit PRESENCE_UPDATE with full user
    else User was deleted (edge case)
        Close->>User: getPublicUser(user_id)
        User->>DB: findOneOrFail(user_id)
        DB-->>User: Error (user not found)
        User-->>Close: Throws error
        Close->>Close: Catch error & create fallback user
        Note over Close: Create minimal PublicUser with<br/>id, default username, etc.
        Close->>Events: Emit PRESENCE_UPDATE with fallback user
    end
    
    Close->>Events: Emit SESSIONS_REPLACE
    Note over Events: Both events succeed regardless<br/>of user deletion status

Loading

Import In IDE

🤖 Prompt for AI Agents

I have created the following plan after thorough exploration and analysis of the codebase. Follow the below plan verbatim. Trust the files and references. Do not re-verify what's written in the plan. Explore only when absolutely necessary. First implement all the proposed file changes and then I'll review all the changes together at the end.

### Observations

I analyzed the GitHub issue and the codebase to understand the problem. The issue is in the `Close.ts` gateway event handler where it tries to fetch a public user for presence updates when a WebSocket connection closes. The current implementation has a try-catch around `User.getPublicUser()` that falls back to `{ id: this.user_id }`, but this fallback object doesn't match the expected `PublicUser` structure.

Looking at the `PublicUserEnum` (lines 39-54 in User.ts), a `PublicUser` should have fields like `username`, `discriminator`, `id`, `public_flags`, `avatar`, etc. The current fallback only provides `id`, which could cause issues downstream when the presence update event is processed.

The `User.getPublicUser()` method uses `findOneOrFail()` which throws when a user is deleted, but the presence update system still needs to work even if the user was deleted mid-connection.

### Approach

I'll improve the error handling in the `Close.ts` file to create a more robust fallback mechanism:

1. **Enhanced Fallback Object**: Instead of just `{ id: this.user_id }`, create a minimal but complete `PublicUser` object with all required fields set to sensible defaults
2. **Improved Error Handling**: Make the catch block more specific and add logging for debugging
3. **Consistent Structure**: Ensure the fallback user object matches the `PublicUser` interface structure to prevent downstream errors

The solution will maintain backward compatibility while ensuring presence updates and session replacement events work reliably even when users are deleted.

### Reasoning

I started by examining the specific file mentioned in the GitHub issue (`src/gateway/events/Close.ts`) and found the problematic code around lines 92-99. I then explored the codebase to understand the `User.getPublicUser()` method, the `PublicUser` interface structure, and how presence updates work. I analyzed the `PublicUserEnum` to understand what fields are required for a proper public user object and identified that the current fallback `{ id: this.user_id }` is insufficient.

## Mermaid Diagram

sequenceDiagram
    participant WS as WebSocket Connection
    participant Close as Close Handler
    participant User as User.getPublicUser()
    participant DB as Database
    participant Events as Event System

    WS->>Close: Connection closes
    Close->>Close: Clean up sessions & voice state
    
    alt User exists in database
        Close->>User: getPublicUser(user_id)
        User->>DB: findOneOrFail(user_id)
        DB-->>User: User data
        User-->>Close: PublicUser object
        Close->>Events: Emit PRESENCE_UPDATE with full user
    else User was deleted (edge case)
        Close->>User: getPublicUser(user_id)
        User->>DB: findOneOrFail(user_id)
        DB-->>User: Error (user not found)
        User-->>Close: Throws error
        Close->>Close: Catch error & create fallback user
        Note over Close: Create minimal PublicUser with<br/>id, default username, etc.
        Close->>Events: Emit PRESENCE_UPDATE with fallback user
    end
    
    Close->>Events: Emit SESSIONS_REPLACE
    Note over Events: Both events succeed regardless<br/>of user deletion status

## Proposed File Changes

### src/gateway/events/Close.ts(MODIFY)

References: 

- src/util/entities/User.ts
- src/util/interfaces/Presence.ts

I'll improve the error handling for the deleted-user edge case by:

1. **Creating a proper fallback user object**: Replace the current `{ id: this.user_id }` fallback with a complete minimal `PublicUser` object that includes all required fields from `PublicUserEnum` with sensible defaults

2. **Enhanced error handling**: Make the catch block more specific and add console logging to help with debugging when this edge case occurs

3. **Ensuring type safety**: The fallback object will match the expected `PublicUser` structure to prevent downstream errors in presence update processing

The changes will be made around lines 92-99 where the current TODO comment and basic fallback exist. I'll replace the current implementation with a more robust solution that creates a minimal but complete user object with:
- `id`: the actual user ID
- `username`: a placeholder indicating deleted user
- `discriminator`: a default value
- `avatar`, `banner`, `bio`: null values
- `bot`: false
- `public_flags`: 0
- Other optional fields: appropriate defaults

This ensures that even when a user is deleted, the presence update and session replacement events can still be emitted successfully without throwing errors.

---

Developer Humor

🔌 When users vanish into the digital void,
Our gateway won't be paranoid!
With fallbacks so neat,
No errors to meet,
Connections close gracefully, null and void! 🚀

---

Execution Information

Branch: master
Commit: 0442d70

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.