Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions api/contacts.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -245,6 +245,10 @@ The implementation automatically:
- Includes tokens in profile picture requests
- Skips tokens for groups and newsletters

## Async compatibility

`is_on_whatsapp` and `get_user_info` work correctly when called from `#[async_trait]` implementations or any context that boxes the returned future (`Box<dyn Future + Send>`). Earlier versions produced a compile error (`"implementation of FnOnce is not general enough"`) that could not be worked around in user code. Fixed in [#826](https://github.com/oxidezap/whatsapp-rust/pull/826) with no API changes.

## Error handling

All methods return `Result<T, anyhow::Error>`. Common errors:
Expand Down
24 changes: 24 additions & 0 deletions changelog/2026-06-10-hrtb-closures.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
---
title: "June 10, 2026 — Contacts: fix async_trait / boxed-future compilation error"
description: "is_on_whatsapp() and get_user_info() now compile correctly when called from #[async_trait] implementations or any context that boxes the returned future."
---

## Bug Fix

**Contacts: `is_on_whatsapp` and `get_user_info` compile in `#[async_trait]` contexts ([#826](https://github.com/oxidezap/whatsapp-rust/pull/826))**

Calling either method from an `#[async_trait]` implementation — or any other context that boxes the returned future — previously produced a hard compiler error:

```
error: implementation of `FnOnce` is not general enough
= note: closure with signature `fn(&'0 IsOnWhatsAppResult) -> (&Jid, Option<&Jid>)`
must implement `FnOnce<(&'1 IsOnWhatsAppResult,)>`, for any two lifetimes `'0` and `'1`...
```

The root cause was inside the library: the internal `persist_lid_mappings` helper received closures that returned references tied to a concrete lifetime. Rust infers such closures at a single lifetime rather than the higher-ranked `for<'r> Fn(&'r _)` form. Because the closure types were embedded in the public methods' future types, the unprovable HRTB obligation leaked to every boxing consumer — nothing in user code could work around it.

**Fix.** The three offending closures are now named `fn` items (`forward_lid_pair`, `reverse_lid_pair`, `user_info_lid_pair`), which implement `Fn` for every lifetime by construction. No API changes, no extra allocations, identical behavior.

A compile-time regression guard (`tests/async_trait_boxed_future_compat.rs`) was added that reproduces the exact consumer shape from the original report — an `#[async_trait]` impl holding an `RwLock<Option<Arc<Client>>>` — and fails to compile if the issue is ever reintroduced.

**No breaking changes.** Fixes [#825](https://github.com/oxidezap/whatsapp-rust/issues/825).
1 change: 1 addition & 0 deletions docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -138,6 +138,7 @@
"group": "Changelog",
"pages": [
"changelog/overview",
"changelog/2026-06-10-hrtb-closures",
"changelog/2026-06-10-server-aware-lookup-probe",
"changelog/2026-06-10-phash-arena-sort",
"changelog/2026-06-10-attrs-inline-smallvec",
Expand Down