Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.
<!-- gh-comment-id:1137141656 -->
@BlackDex commented on GitHub (May 25, 2022):
Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @PeterRob on GitHub (May 25, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2500
Subject of the issue
After upgrading to version 1.25.0 the vault appears to be empty when opened in the web browser
This is similar to issue #2484 that was closed and subsequently 2 people reported the same problem after closure https://github.com/dani-garcia/vaultwarden/issues/2484
Deployment environment
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden: DOMAIN, SIGNUPS_ALLOWED, SIGNUPS_VERIFY, SIGNUPS_VERIFY_RESEND_TIME, SIGNUPS_VERIFY_RESEND_LIMIT, INVITATIONS_ALLOWED, SHOW_PASSWORD_HINT, ADMIN_TOKEN, DISABLE_ADMIN_TOKEN, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD, SMTP_TIMEOUT
Install method:
Built from source
Clients used:
Browser
Reverse proxy and version:
Caddy
MySQL/MariaDB or PostgreSQL version:
Mariadb
Other relevant details:
Steps to reproduce
Expected behaviour
The vault appears to be empty
Actual behaviour
The vault to be available in the web browser
Troubleshooting data
Vaultwarden log:
thread 'rocket-worker-thread' panicked at 'Error loading attachments: DatabaseError(__Unknown, "Commands out of sync; you can't run this command now")': src/db/models/attachment.rs:196
0: backtrace::backtrace::trace
1: backtrace::capture::Backtrace::new
2: vaultwarden::init_logging::{{closure}}
3: std::panicking::rust_panic_with_hook
4: std::panicking::begin_panic_handler::{{closure}}
5: std::sys_common::backtrace::__rust_end_short_backtrace
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
9: tokio::runtime::enter::exit
10: tokio::runtime::thread_pool::worker::block_in_place
11: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
12: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
13: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
14: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
15: tokio::runtime::task::core::CoreStage::poll
16: tokio::runtime::task::harness::poll_future
17: tokio::runtime::task::harness::Harness<T,S>::poll
18: std::thread::local::LocalKey::with
19: tokio::runtime::thread_pool::worker::Context::run_task
20: tokio::runtime::thread_pool::worker::Context::run
21: tokio::macros::scoped_tls::ScopedKey::set
22: tokio::runtime::thread_pool::worker::run
23: <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll
24: tokio::runtime::task::harness::Harness<T,S>::poll
25: tokio::runtime::blocking::pool::Inner::run
26: std::sys_common::backtrace::__rust_begin_short_backtrace
27: core::ops::function::FnOnce::call_once{{vtable.shim}}
28: std::sys::unix::thread::Thread::new::thread_start
@BlackDex commented on GitHub (May 25, 2022):
Closing this as a duplicate of #2484 (After re-opening it).
Please update that issue with the same information so that we can keep all together.