Skip to content

fix(trae): send the aha device id shape the checkin backend expects - #206

Merged
caigee-cmd merged 2 commits into
caigee-cmd:mainfrom
xingyicjj:fix/trae-checkin-device-id
Sep 19, 2026
Merged

caigee-cmd merged 2 commits into
caigee-cmd:mainfrom
xingyicjj:fix/trae-checkin-device-id

Conversation

@xingyicjj

@xingyicjj xingyicjj commented Sep 19, 2026

Copy link
Copy Markdown
Contributor

Fixes Trae CN check-in, which currently cannot succeed for any account added through the login flow.

The problem

EnsureDevice fills an empty device_id with randomHex(16):

credential.DeviceID = randomHex(16)   // e.g. 3ee0250fe3e0e6e03cdd8054e3a01a7b

SetUgHeaders then forwards it verbatim as X-Device-Id. The UG check-in backend keys its per-device daily limit on that header and answers a bare hex id with:

HTTP 200  {"code":9074,"message":"当前参与用户太多,请稍后再试"}

The message reads as a rate limit, so it looks like the service is simply busy — but retrying never helps, and it happens at every hour of the day. The device dimension is the real axis. Same account, same token, same host, seconds apart:

X-Device-Id sent result
3ee0250fe3e0e6e03cdd8054e3a01a7b (what a login-flow credential holds) 9074 当前参与用户太多
aha-b9efcd18de307d33417bce2b3e27a0b2 {"code":0,"message":"success"}
aha-cfac6e546e2386ec29e13335393d79dc {"code":0,"message":"success"}
1800324722220809 (the Trae client's own id, already used today) 9095 当前设备今日已经签到

Trae's own client sends aha-<hex>[ICDRS] did: 1800324722220809, ldid: aha-d1f737a30c4f966fbca6b0e7ad1718ce in its logs — which is why the client checks in on the same machine while cli2api does not.

One detail worth knowing while reading the status envelope: it carries did_checked_in alongside checked_in. That second flag is the per-device state, and it is what the client's UI shows as "当前设备今日已经签到".

The fix

SetUgHeaders normalises the stored id to the aha-<hex> shape before sending. Only the UG endpoints are affected — login URLs and the SOLO/chat headers keep the raw value, so nothing else changes behaviour.

Existing credentials work as-is: no re-login, no migration. Distinct ids stay distinct, so the one-device-one-account-per-day rule still holds.

Test plan

  • go test ./... — all packages pass on this branch (d574006 + these two commits)
  • go vet ./...
  • cd worker && npm test — 77 pass, 0 fail
  • cd frontend && npm run build && npm run lint — build ok, 0 errors (warnings are pre-existing)
  • Added changelog/unreleased/trae-checkin-device-id.md (python scripts/release-notes.py validate passes)
  • No tokens, auth blobs, raw captures, or host details in the diff

Live verification

Checked against the running service with four Trae CN accounts: a bare hex device id returns 9074 on every claim, the same id prefixed with aha- returns {"code":0} and the account flips to checked_in: true.

The UG checkin backend keys its per-device daily limit on X-Device-Id and answers a bare hex id with code 9074, whose message reads as a rate limit but is a device-identity refusal.

EnsureDevice issues randomHex(16) and SetUgHeaders forwarded it verbatim, so every browser-login account fails to check in even though the claim flow itself is correct. Trae's own client sends aha-<hex>.

Normalising in SetUgHeaders keeps existing credentials working without a re-login and keeps distinct ids distinct, so each account still maps to its own device.
@caigee-cmd
caigee-cmd merged commit 064a4cb into caigee-cmd:main Sep 19, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants