9351e91 Do not fail login when push device registration fails
📊 Changes
1 file changed (+6 additions, -1 deletions)
View changed files
📝src/api/identity.rs (+6 -1)
📄 Description
Problem
With PUSH_ENABLED=true, re-authenticating an existing device (e.g. after the session expires or a forced re-login) fails: POST /identity/connect/token returns 400, with this in the log:
[vaultwarden::api::push][ERROR] Unexpected push token received from bitwarden server: error decoding response body
POST /identity/connect/token => 400 Bad Request
The initial login succeeds; only a later re-login fails. Reported in #7371 (iOS + OIDC SSO, but it isn't SSO-specific).
Cause
In authenticated_response (src/api/identity.rs), push registration runs only for already-known devices and its error is propagated with ?:
register_push_device calls get_auth_api_token(), which returns Err when the push identity server's response can't be deserialized (src/api/push.rs, err!("Unexpected push token received from bitwarden server: …")). The ? propagates that out of authenticated_response, so it becomes the token endpoint's 400. The !device.is_new() gate is why only re-authentication is affected — the very first login takes the is_new() path and skips registration.
Fix
Handle the registration best-effort: log the error and continue, mirroring the new-device login email a few lines above (also a non-essential side effect of login). The device is still saved right after, so push keeps working once the relay/identity endpoint recovers, and authentication no longer fails when it misbehaves.
Verification
cargo fmt --all -- --check and cargo clippy --features sqlite -- -D warnings both pass on the change.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/dani-garcia/vaultwarden/pull/7378
**Author:** [@maximilize](https://github.com/maximilize)
**Created:** 6/26/2026
**Status:** 🔄 Open
**Base:** `main` ← **Head:** `fix/7371-push-best-effort`
---
### 📝 Commits (1)
- [`9351e91`](https://github.com/dani-garcia/vaultwarden/commit/9351e91de073862776f587914f26b901e0d829c4) Do not fail login when push device registration fails
### 📊 Changes
**1 file changed** (+6 additions, -1 deletions)
<details>
<summary>View changed files</summary>
📝 `src/api/identity.rs` (+6 -1)
</details>
### 📄 Description
## Problem
With `PUSH_ENABLED=true`, re-authenticating an existing device (e.g. after the session expires or a forced re-login) fails: `POST /identity/connect/token` returns `400`, with this in the log:
```
[vaultwarden::api::push][ERROR] Unexpected push token received from bitwarden server: error decoding response body
POST /identity/connect/token => 400 Bad Request
```
The initial login succeeds; only a later re-login fails. Reported in #7371 (iOS + OIDC SSO, but it isn't SSO-specific).
## Cause
In `authenticated_response` (`src/api/identity.rs`), push registration runs only for already-known devices and its error is propagated with `?`:
```rust
if !device.is_new() {
register_push_device(device, conn).await?;
}
```
`register_push_device` calls `get_auth_api_token()`, which returns `Err` when the push identity server's response can't be deserialized (`src/api/push.rs`, `err!("Unexpected push token received from bitwarden server: …")`). The `?` propagates that out of `authenticated_response`, so it becomes the token endpoint's `400`. The `!device.is_new()` gate is why only re-authentication is affected — the very first login takes the `is_new()` path and skips registration.
## Fix
Handle the registration best-effort: log the error and continue, mirroring the new-device login email a few lines above (also a non-essential side effect of login). The device is still saved right after, so push keeps working once the relay/identity endpoint recovers, and authentication no longer fails when it misbehaves.
## Verification
`cargo fmt --all -- --check` and `cargo clippy --features sqlite -- -D warnings` both pass on the change.
Fixes #7371
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
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.
📋 Pull Request Information
Original PR: https://github.com/dani-garcia/vaultwarden/pull/7378
Author: @maximilize
Created: 6/26/2026
Status: 🔄 Open
Base:
main← Head:fix/7371-push-best-effort📝 Commits (1)
9351e91Do not fail login when push device registration fails📊 Changes
1 file changed (+6 additions, -1 deletions)
View changed files
📝
src/api/identity.rs(+6 -1)📄 Description
Problem
With
PUSH_ENABLED=true, re-authenticating an existing device (e.g. after the session expires or a forced re-login) fails:POST /identity/connect/tokenreturns400, with this in the log:The initial login succeeds; only a later re-login fails. Reported in #7371 (iOS + OIDC SSO, but it isn't SSO-specific).
Cause
In
authenticated_response(src/api/identity.rs), push registration runs only for already-known devices and its error is propagated with?:register_push_devicecallsget_auth_api_token(), which returnsErrwhen the push identity server's response can't be deserialized (src/api/push.rs,err!("Unexpected push token received from bitwarden server: …")). The?propagates that out ofauthenticated_response, so it becomes the token endpoint's400. The!device.is_new()gate is why only re-authentication is affected — the very first login takes theis_new()path and skips registration.Fix
Handle the registration best-effort: log the error and continue, mirroring the new-device login email a few lines above (also a non-essential side effect of login). The device is still saved right after, so push keeps working once the relay/identity endpoint recovers, and authentication no longer fails when it misbehaves.
Verification
cargo fmt --all -- --checkandcargo clippy --features sqlite -- -D warningsboth pass on the change.Fixes #7371
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.