[GH-ISSUE #266] WebSockets stop working after a while #8951

New Issue

GiteaMirror · 2026-04-20T11:48:28-05:00

GiteaMirror commented

2026-04-20 11:48:28 -05:00

Originally created by @pew on GitHub (Nov 21, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/266

Hi,

I'm using the current bitwarden_rs mprasil/bitwarden:1.4.0-alpine docker image with WEBSOCKET_ENABLED=true configured (and caddy as my proxy, also with websockets enabled), I also have a healthcheck configured for port 80 and 3012 within the container.

After one to two minutes the healthcheck for 3012 is failing. Container log:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21

with the backtrace enabled:

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::panicking::panic
             at libcore/panicking.rs:52
   9: <bitwarden_rs::api::notifications::WSFactory as ws::factory::Factory>::connection_lost
  10: <ws::io::Handler<F>>::check_active
  11: <ws::io::Handler<F>>::run
  12: <ws::WebSocket<F>>::listen

Originally created by @pew on GitHub (Nov 21, 2018). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/266 Hi, I'm using the current bitwarden_rs `mprasil/bitwarden:1.4.0-alpine` docker image with `WEBSOCKET_ENABLED=true` configured (and caddy as my proxy, also with websockets enabled), I also have a healthcheck configured for port 80 and 3012 within the container. After one to two minutes the healthcheck for 3012 is failing. Container log: ``` thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21 ``` with the backtrace enabled: ``` stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:476 5: std::panicking::continue_panic_fmt at libstd/panicking.rs:390 6: rust_begin_unwind at libstd/panicking.rs:325 7: core::panicking::panic_fmt at libcore/panicking.rs:77 8: core::panicking::panic at libcore/panicking.rs:52 9: <bitwarden_rs::api::notifications::WSFactory as ws::factory::Factory>::connection_lost 10: <ws::io::Handler<F>>::check_active 11: <ws::io::Handler<F>>::run 12: <ws::WebSocket<F>>::listen ```

GiteaMirror closed this issue

2026-04-20 11:48:29 -05:00

GiteaMirror commented

2026-04-20 11:48:30 -05:00

@dani-garcia commented on GitHub (Nov 21, 2018):

I removed the unwrap that was making the code panic. It should be fixed now in the latest master

@dani-garcia commented on GitHub (Nov 21, 2018): I removed the unwrap that was making the code panic. It should be fixed now in the latest master

GiteaMirror commented

2026-04-20 11:48:31 -05:00

@mprasil commented on GitHub (Nov 21, 2018):

Note that there's a fix in #263 to allow us building alpine image again. So if you want to test the fix now, you need to build manually (with the alpine fix applied) or wait until that gets merged.

@mprasil commented on GitHub (Nov 21, 2018): Note that there's a fix in #263 to allow us building alpine image again. So if you want to test the fix now, you need to build manually (with the alpine fix applied) or wait until that gets merged.

GiteaMirror commented

2026-04-20 11:48:32 -05:00

@mprasil commented on GitHub (Nov 21, 2018):

The changes were now merged and the alpine image is now building. Give it about an hour and it should be available.

@mprasil commented on GitHub (Nov 21, 2018): The changes were now merged and the [alpine image is now building](https://hub.docker.com/r/mprasil/bitwarden/builds/bjmed4lvre5agtan9dgfvea/). Give it about an hour and it should be available.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#8951