Skip to content

fix: Replace unwrap with proper error handling in WebSocket subscribe handler#4696

Open
Shiven0504 wants to merge 1 commit intoclockworklabs:masterfrom
Shiven0504:fix/subscribe-unwrap-panic
Open

fix: Replace unwrap with proper error handling in WebSocket subscribe handler#4696
Shiven0504 wants to merge 1 commit intoclockworklabs:masterfrom
Shiven0504:fix/subscribe-unwrap-panic

Conversation

@Shiven0504
Copy link
Contributor

Description of Changes

Replace .unwrap() with .map_err(log_and_500)? on the get_database_by_identity() call in the WebSocket subscribe handler (crates/client-api/src/routes/subscribe.rs).

This was the only call site in the codebase using .unwrap() for this method — all four other call sites in database.rs already use .map_err(log_and_500)?. A transient database error during WebSocket connection setup would panic the server instead of returning an HTTP 500.

Closes #4686

API and ABI breaking changes

None.

Expected complexity level and risk

1 — Single-token replacement matching the established pattern used everywhere else.

Testing

  • Verified the fix matches the error-handling pattern used at all other get_database_by_identity call sites
  • Confirmed log_and_500 is already imported in the file

… handler

`get_database_by_identity()` was the only call site using `.unwrap()`
instead of `.map_err(log_and_500)?`, which could panic the server on a
transient database error during WebSocket connection setup.

Closes clockworklabs#4686
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unwrap in WebSocket subscribe handler can panic on database lookup failure

1 participant