## 📝 Summary
This PR fixes a regression that caused the following error during GitHub
OAuth login:
> Unable to parse JSON response from
[https://github.com/login/oauth/access_token](https://github.com/login/oauth/access_token)
Related issue:
[https://github.com/toeverything/AFFiNE/issues/14334](https://github.com/toeverything/AFFiNE/issues/14334)
Regression introduced in:
[https://github.com/toeverything/AFFiNE/pull/14061](https://github.com/toeverything/AFFiNE/pull/14061)
---
## 🎯 Background
GitHub’s OAuth access token endpoint returns different response formats
depending on the request headers.
To receive a JSON response, the request must include:
```
Accept: application/json
```
If the `Accept` header is missing, GitHub responds with:
```
application/x-www-form-urlencoded
```
The current implementation assumes a JSON response and parses it
directly.
When a non-JSON response is returned, JSON parsing fails,
breaking the OAuth login flow.
---
## 🔍 Traffic Analysis (tcpdump)
Network path:
affine-graphql → (HTTPS) → envoy → (HTTP, tcpdump) → envoy → GitHub
### Observed Request
```
POST /login/oauth/access_token HTTP/1.1
host: github-proxy.com
content-type: application/x-www-form-urlencoded
accept: */*
...
```
### Observed Response
```
HTTP/1.1 200 OK
date: Sat, 28 Feb 2026 14:47:43 GMT
content-type: application/x-www-form-urlencoded; charset=utf-8
...
```
The `Accept` header was `*/*` instead of `application/json`,
causing GitHub to return a form-urlencoded response.
---
## 🐛 Root Cause
PR #14061 introduced a side effect in the request configuration.
Although the `Accept` header was initially defined,
the request options were later overwritten by the `init` parameter.
Because `init.headers` replaced the previously defined headers object,
the required header was lost.
Resulting in:
* Missing `Accept: application/json`
* GitHub returning `application/x-www-form-urlencoded`
* JSON parsing failure
* OAuth login failure
---
## 🔧 Changes
### 1️⃣ Fix header overwrite order
* Process the incoming `init` parameter first
* Explicitly overwrite required headers afterward
* Ensure `Accept: application/json` is always enforced
---
## 💥 Breaking Changes
None.
---
## 🧪 How to Test
1. Configure GitHub OAuth.
2. Attempt login via GitHub.
3. Verify that:
* The request contains `Accept: application/json`
* The response content-type is `application/json`
* No JSON parsing error occurs
* OAuth login completes successfully
---
## 📌 Notes
This change restores correct OAuth behavior and prevents regression
caused by header overwriting introduced in #14061.
The same header overwrite pattern identified in this issue
was also found in the calendar module and has been corrected there as
well.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved backend HTTP header handling for external integrations to
avoid unintended header overrides, ensuring content-type and encoding
hints are applied consistently and improving reliability of service
requests.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
2e95d91093