- Shipped
- August 5, 2026 at 7:01 PM UTC
- Author
- Kamo
- Commit
- 8b95800
All / Calls / Texts / Emails failed with "We couldn't load this lead's communications". The backend was fine — direct calls returned 200 with real entries. The BFF route was corrupting the request. forwardToApi already carries the caller's query string through (`new URL(request.url).search`). This route built its own suffix as well, so the forwarded URL had two `?`. That is not a syntax error: everything after the FIRST `?` is the query string, so the backend received `size=25?channel=ALL` and Spring returned 400 binding it to an int ("For input string: 25?channel=ALL,25"). The counts route next door was unaffected because it forwards no params — which is exactly why the tab looked half-broken rather than obviously misrouted. Two things made this take longer to find than it should have, both fixed: the route collapsed every upstream failure into one opaque string, and the client threw away the status. Both now log what actually came back. forwardToApi also documents that it owns the query string, since the trap is invisible at the call site.