[Bug]: 安卓客户端无法登录，提示：中继返回了无效的账号响应

[tecgic]

Summary

下载安卓apk安装后，点击登录，跳转浏览器使用邮箱或github登录，显示登录完成，返回APP提示：中继返回了无效的账号响应

Area

Desktop app

Reproduction or evidence

下载安卓apk安装后，点击登录，跳转浏览器使用邮箱或github登录，显示登录完成，返回APP提示：中继返回了无效的账号响应

Environment, if relevant

No response

[braindeadz]

Root cause analysis for the Android sign-in failure (account_malformed_response)

Same symptom here: APK installed, browser sign-in completes ("login complete"), app shows "The relay returned an invalid account response." (中继返回了无效的账号响应。). Environment: APK OpenBitFun-1.0.0-beta.apk from v1.0.2 (size 4634953, sha256 9f4bf757a597d39297445a8722040096d9414c125c977fb5324e5952f4f62421, asset uploaded 2026-09-28 12:46Z), Android 15 / Galaxy S25, both GitHub and email-code sign-in affected.

1. Where the message comes from

account_malformed_response (src/apps/mobile/android/app/src/main/res/values-zh/strings.xml:59) is emitted for AccountFailureReason.MALFORMED_RESPONSE, which comes from CloudAccountFailure.MALFORMED_RESPONSE. In CloudAccountClient.statusFailure(), every status that is not 2xx / 401 / 403 / 429 / 5xx maps to this reason, so 400, 404, 409, 410 and 422 all render as "invalid account response". JSON that fails to decode, and any non-CloudAccountException thrown inside AccountStore.login(), land on the same string (AccountStore.kt:301). The message therefore says nothing about credentials: it is "the relay answered something unusable", not "wrong account".

2. The relay endpoints themselves are healthy

Reproduced server-side, using exactly the request shapes the APK sends (/api/auth/github/start?methods=all, /api/auth/github/poll, /api/auth/login with device_kind: "mobile", clientVersion, clientProtocol), against https://remote.openbitfun.com/v/1.0.2:

start            -> 200 {authorizationUrl: auth.openbitfun.com/sign-in#ticket=..., ...}
auth/email/send  -> 200 {challengeId}
auth/email/verify-> 200 {redirectUrl: .../email/complete?grant=...}
poll             -> 200 {"status":"authorized","tokens":{accessToken, refreshToken, ...}}
login            -> 200 {token, user_id}      # same body the APK sends

So the flow works end to end from a clean client, and the APK's paths/field names match production.

3. The actual defect: the poll grant is single-use, and the client cannot recover

The redemption returned by poll is once-only. Measured repeatedly, same transaction:

poll #1 after authorization -> 200 {"status":"authorized","tokens":{...}}   <- tokens delivered once
poll #2                     -> 200 {"status":"consumed"}                    <- no tokens, ever again
poll #3, #4 ...             -> 200 {"status":"consumed"}

AuthorizationPoll.awaitAccessToken() (AccountStore.kt:660-697) polls every pollIntervalSeconds and only understands authorized (with tokens), expired and denied. consumed is not handled, so:

• a single lost or duplicated poll while the user is still in the browser (radio drop, app resumed, retry after a timeout) burns the grant permanently and the sign-in can never produce a token;
• whichever side redeems first, the other side only ever sees consumed.

Consequences: the client keeps polling until start.expiresAt, and any 4xx met on the way is surfaced immediately as the reported message. Note also that POST /api/auth/login answers 400 {"error":"invalid login parameters"} (not 401) when access_token cannot be verified, which lands in the client's "else" branch and is displayed as "invalid account response" as well. Other observed statuses: unknown transaction -> 503, wrong transactionSecret -> 401, transactionId longer than 256 chars -> 400.

4. Additional observations

• GET /v/1.0.2/api/info on production reports {"version":"1.0.1","protocol_version":3} while the app targets /v/1.0.2; every other version path returns 410 Gone, so no older APK can work either.
• The APK was built from main around 91b05f1c (i.e. it contains a58f6548 refactor(mobile): replace QR pairing with account sign-in, merged as refactor(mobile): replace QR pairing with account sign-in #3242), so this is not a stale build.

5. Suggested fixes

1. src/crates/services/relay-service/src/routes/auth.rs::github_poll (most important): make the poll idempotent. Cache the first non-pending success payload per transaction (bounded map, TTL = transaction expiresAt, cleared on completion) and replay it for repeated polls with the same transaction_id/transaction_secret, instead of forwarding every poll to the identity authority. A duplicate poll can currently destroy a sign-in.
2. AccountStore.AuthorizationPoll.awaitAccessToken: handle terminal statuses explicitly. Treat consumed (and any status that is neither pending/authorized/expired/denied) as a definitive failure with its own reason, so the user gets an actionable message instead of an endless poll that ends in a generic error.
3. /api/auth/login: answer 401 for an unverifiable access_token instead of 400 invalid login parameters; keep 410/expired distinct. This alone stops a whole class of "invalid account response" reports.
4. Client: surface CloudAccountException.detail/HTTP status for non-retryable failures (it is captured in the log but never shown).
5. Re-publish the Android beta APK once fixed: the current asset still carries the September 28 build.

Happy to test a new APK on a Galaxy S25 / Android 15, and to provide adb logcat transport lines (account request rejected path=... status=..., account response undecodable ...) if you want device-side confirmation of which hop is hit first.

Minimal repro script (Python 3, no dependencies beyond stdlib + a throwaway mailbox)

The script used above: POST /api/auth/github/start?methods=all on the relay, then auth.openbitfun.com/api/v1/auth/email/send|verify with the ticket, then two consecutive POST /api/auth/github/poll with the same transactionId/transactionSecret and print both bodies, then POST /api/auth/login with the token from the first poll. The two poll responses differ exactly as shown in section 3.

[braindeadz]

Follow-up with two things: a correction of one claim in my previous comment, and a concrete patch proposal.

Correction

I wrote that /api/auth/login answers 400 invalid login parameters for an unverifiable access_token. That is wrong: measured on production just now, an unverifiable token answers 401 {"error":"Sign in to continue"} (which the app maps to AUTHENTICATION, not to the reported message). My earlier 400 came from the all-zero public_key in my own test body, not from the token. The measured matrix:

request	status	body
valid shape, bogus access_token	401	{"error":"Sign in to continue"}
public_key decoding to 32 zero bytes	400	{"error":"invalid login parameters"}
request_id not a UUID	400	{"error":"invalid login parameters"}
device_kind outside desktop/cli/mobile/watch	400	{"error":"invalid login parameters"}

So the 400-on-login path is not the one this report hits, and points 3 of my previous list should be read accordingly: the client-side finding stands (400/404/409/410/422 are all rendered as "invalid account response"), but the relay is not returning 400 for a rejected token.

The fragile part remains the single-use poll grant

Re-measured, unchanged: the first POST /api/auth/github/poll after authorization returns {"status":"authorized","tokens":{...}}, and every following poll for the same transaction_id returns {"status":"consumed"} without tokens. The relay forwards each poll to the identity authority, which redeems the transaction once. Both native clients poll on an interval, so any duplicated request, any dropped response that the client retries, and any app resume that re-polls burns the grant, after which that sign-in can never yield a token, and the client (which only understands authorized/expired/denied) just keeps polling until the window closes.

Because this is a relay-side defect, fixing it needs no app update: the APKs already installed would start working immediately. That is the fastest path to closing this report, and it is why I would ask for it ahead of a rebuild.

Proposed patch 1: make the poll idempotent (relay), src/crates/services/relay-service/src/identity.rs

Replay the outcome the authority already gave for a transaction, instead of asking again. Same bounded-map pattern the host flow already uses (src/crates/services/services-integrations/src/account_identity/flow.rs). Not compiled here (no Rust toolchain on my side), so please treat it as a proposal:

// add to the imports at the top of the file
use std::{
    collections::HashMap,
    sync::{Arc, Mutex, OnceLock},
    time::{Duration, SystemTime, UNIX_EPOCH},
};

/// Terminal sign-in outcomes, keyed by transaction.
///
/// The authority redeems a transaction exactly once: the first poll that finds
/// it completed returns the tokens, and every later poll for the same
/// transaction answers `consumed` without them. Native clients poll on an
/// interval and can lose a response (a dropped connection, a backgrounded
/// phone, a duplicated request), which would turn a completed sign-in into a
/// dead one. Replaying what this relay already received makes the poll
/// idempotent for the length of the transaction window.
fn completed_authorizations() -> &'static Mutex<HashMap<String, (serde_json::Value, i64)>> {
    static COMPLETED: OnceLock<Mutex<HashMap<String, (serde_json::Value, i64)>>> = OnceLock::new();
    COMPLETED.get_or_init(|| Mutex::new(HashMap::new()))
}

/// How long a terminal answer is replayed. The authority hands the transaction
/// out for a few minutes; a client that redeems it late stays inside this.
const POLL_REPLAY_SECS: i64 = 900;

fn now_secs() -> i64 {
    SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .unwrap_or_default()
        .as_secs() as i64
}

fn replayed_poll(transaction_id: &str) -> Option<serde_json::Value> {
    let mut completed = completed_authorizations()
        .lock()
        .unwrap_or_else(|poisoned| poisoned.into_inner());
    completed.retain(|_, (_, expires_at)| *expires_at > now_secs());
    completed.get(transaction_id).map(|(payload, _)| payload.clone())
}

fn remember_poll(transaction_id: &str, payload: &serde_json::Value) {
    // Pending is not an outcome: the next poll must still ask.
    if payload.get("status").and_then(|status| status.as_str()) == Some("pending") {
        return;
    }
    let mut completed = completed_authorizations()
        .lock()
        .unwrap_or_else(|poisoned| poisoned.into_inner());
    completed.retain(|_, (_, expires_at)| *expires_at > now_secs());
    completed.insert(
        transaction_id.to_string(),
        (payload.clone(), now_secs() + POLL_REPLAY_SECS),
    );
}

and in poll_auth, after the existing length validation:

    if let Some(payload) = replayed_poll(transaction_id) {
        return Ok(payload);
    }
    let payload = self
        .auth_request(
            "auth/desktop/poll",
            serde_json::json!({
                "transactionId": transaction_id,
                "transactionSecret": transaction_secret,
            }),
        )
        .await?;
    remember_poll(transaction_id, &payload);
    Ok(payload)

The guards are released before any await, so an std::sync::Mutex is safe here; a unit test can assert that two poll_auth calls against a stub authority produce one upstream request and identical payloads.

Proposed patch 2: stop the silent loop in the app, AccountStore.kt (AuthorizationPoll.awaitAccessToken)

Independent of the relay fix, a status that is not pending will never become authorized, so the client should stop and name it instead of polling for the rest of the window:

            if (result.status == "expired" || result.status == "denied") break
+           // The authority redeems a transaction once; anything that is not
+           // `pending` is terminal, so polling cannot recover it.
+           if (result.status != "pending") {
+               log.warn("account authorization poll terminal status=${result.status}")
+               break
+           }

What I can provide

I can retest within minutes on a Galaxy S25 / Android 15 (APK 9f4bf757a597d39297445a8722040096d9414c125c977fb5324e5952f4f62421, v1.0.2 asset of 2026-09-28 12:46Z), and I can attach adb logcat transport lines (account request rejected path=… status=…, account response undecodable …) to pin down which hop the phone hits first, if you would rather see the device side before changing the relay.

[braindeadz]

One deployment note before the next APK goes out, since the versioned path is easy to miss: production only answers /v/1.0.2 today, and /api/** without a version prefix, /v/1.0.0, /v/1.0.1 and /v/1.0.3 all return 410 Gone (nginx). The Android build in the v1.0.2 release targets https://remote.openbitfun.com/v/1.0.2, which is why it reaches the relay at all.

So if a fixed APK is built against a newer path (say /v/1.0.3), the relay must be reached for that path in the same release, otherwise every sign-in fails at the first request with the same class of error. GET /v/1.0.2/api/info also still reports {"version":"1.0.1"}, which suggests the deployed relay is a 1.0.1 build behind a 1.0.2 path; worth confirming that the build serving the versioned path is the one intended.

PR #3248 addresses the single-use poll described above (relay-side, so no app update is needed for already-installed APKs).