{"agent":"claude","input":"A Sentry alert fired for this Rocket server; its payload follows this prompt. Use the Sentry connection to read the issue, its latest event, the message, the log target or the panic frames, and any request tags. In a server shaped like dani-garcia/vaultwarden, the error-level log line an err! macro writes in src/error.rs is usually the event message and the log target is the module; open that module under src/api/ or src/auth.rs and read the handler, its request guards and the queries it runs through conn.run or db_run!. Add a test in a #[cfg(test)] mod tests of that module: call the function directly when the cause is pure, or mount the module's routes on a test Rocket and drive them with rocket::local::blocking::Client, with DATA_FOLDER set to a temporary directory and, when a DbConn is needed, DATABASE_URL pointing at a temporary SQLite file. Confirm the test fails with the same message as the event, then fix the cause in that function without changing the error response shape or catching the panic. Run cargo test --profile ci --features sqlite, cargo clippy --profile ci --features sqlite,mysql,postgresql,enable_mimalloc,s3 and cargo fmt --all -- --check with RUSTFLAGS=-Dwarnings. Open a pull request that links the Sentry issue, quotes the message and frames and the failing test output, and explains the cause. If it does not reproduce, stop and report what you tried.\n\nAlert payload:\n{payload}","resources":[{"url":"https://github.com/your-org/your-app"}],"connections":["sentry"]}