2c97b41 fix(sends): emit hideEmail as non-null boolean in sync response
📊 Changes
1 file changed (+1 additions, -1 deletions)
View changed files
📝src/db/models/send.rs (+1 -1)
📄 Description
Problem
GET /api/sync returns "hideEmail": null for Sends whose hide_email column is NULL. The sends.hide_email column is Nullable<Bool> with no default (added in migration 2021-05-11-205202_add_hide_email), so it is NULL for older Sends and any code path that leaves it unset.
The Bitwarden Android client deserializes SyncResponseJson.Send.hideEmail as a non-null Kotlin Boolean and throws a JsonDecodingException, aborting the entire sync. Web, desktop and CLI clients coerce null to false, so only accounts with at least one Send are affected, and only on Android.
The official Bitwarden server treats hideEmail as non-nullable.
Fix
Default None to false at the serialization boundary in Send::to_json():
"hideEmail": self.hide_email.unwrap_or(false),
The field stays Option<bool> internally. No DB migration is required, and this fixes both existing NULL rows and any future NULLs.
🔄 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/7283
**Author:** [@kvdb](https://github.com/kvdb)
**Created:** 6/1/2026
**Status:** 🔄 Open
**Base:** `main` ← **Head:** `fix/send-hideemail-non-null`
---
### 📝 Commits (1)
- [`2c97b41`](https://github.com/dani-garcia/vaultwarden/commit/2c97b41e879a84f99147fcae299f4f7404e377cf) fix(sends): emit hideEmail as non-null boolean in sync response
### 📊 Changes
**1 file changed** (+1 additions, -1 deletions)
<details>
<summary>View changed files</summary>
📝 `src/db/models/send.rs` (+1 -1)
</details>
### 📄 Description
### Problem
`GET /api/sync` returns `"hideEmail": null` for Sends whose `hide_email` column is NULL. The `sends.hide_email` column is `Nullable<Bool>` with no default (added in migration `2021-05-11-205202_add_hide_email`), so it is NULL for older Sends and any code path that leaves it unset.
The Bitwarden Android client deserializes `SyncResponseJson.Send.hideEmail` as a non-null Kotlin `Boolean` and throws a `JsonDecodingException`, aborting the **entire** sync. Web, desktop and CLI clients coerce null to `false`, so only accounts with at least one Send are affected, and only on Android.
The official Bitwarden server treats `hideEmail` as non-nullable.
### Fix
Default `None` to `false` at the serialization boundary in `Send::to_json()`:
```rust
"hideEmail": self.hide_email.unwrap_or(false),
```
The field stays `Option<bool>` internally. No DB migration is required, and this fixes both existing NULL rows and any future NULLs.
---
<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/7283
Author: @kvdb
Created: 6/1/2026
Status: 🔄 Open
Base:
main← Head:fix/send-hideemail-non-null📝 Commits (1)
2c97b41fix(sends): emit hideEmail as non-null boolean in sync response📊 Changes
1 file changed (+1 additions, -1 deletions)
View changed files
📝
src/db/models/send.rs(+1 -1)📄 Description
Problem
GET /api/syncreturns"hideEmail": nullfor Sends whosehide_emailcolumn is NULL. Thesends.hide_emailcolumn isNullable<Bool>with no default (added in migration2021-05-11-205202_add_hide_email), so it is NULL for older Sends and any code path that leaves it unset.The Bitwarden Android client deserializes
SyncResponseJson.Send.hideEmailas a non-null KotlinBooleanand throws aJsonDecodingException, aborting the entire sync. Web, desktop and CLI clients coerce null tofalse, so only accounts with at least one Send are affected, and only on Android.The official Bitwarden server treats
hideEmailas non-nullable.Fix
Default
Nonetofalseat the serialization boundary inSend::to_json():The field stays
Option<bool>internally. No DB migration is required, and this fixes both existing NULL rows and any future NULLs.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.