fix(dashboard): display WeChat QR code for iLink login#1572
Merged
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Contributor
|
I hope to release a lastest version today after this merger |
Contributor
Author
yeah, I will release a new version after ci all passed. |
houko
force-pushed
the
fix/wechat-qr-display
branch
from
March 24, 2026 10:45
20fdf4d to
0100404
Compare
Add /api/channels/wechat/qr/start and /qr/status endpoints that proxy to the iLink API, mirroring the existing WhatsApp QR pattern. On the dashboard, channels with setup_type "qr" now open a QR login dialog instead of the config form. The dialog renders the QR code via the qrcode npm package, polls for scan confirmation, and auto-saves the bot_token on success. Closes #1560
houko
force-pushed
the
fix/wechat-qr-display
branch
from
March 24, 2026 10:47
0100404 to
010a8c3
Compare
split_whitespace() already handles leading/trailing whitespace, so the preceding trim() call is unnecessary.
kernel.rs:2119 calls block_in_place which requires multi-threaded
runtime. Changed #[tokio::test] → #[tokio::test(flavor = "multi_thread")]
in all integration/load test files (34+2+7 = 43 tests).
Also fixed workflow list API response format in tests (now returns
{ workflows: [...] } instead of bare array).
The test was failing on CI because ~/.librefang doesn't exist on runners. Filter "does not exist" warnings alongside the existing "is not set" filter since both are environment-dependent, not structural.
…blocking - Fix QR login token not saving: frontend sent `bot_token` but backend expects `bot_token_env` - Fix agents directory: all paths now use `~/.librefang/workspaces/agents` instead of `~/.librefang/agents` - Fix iLink QR status timeout: increase to 35s for long-poll, treat timeout as "waiting" - Fix WeChat adapter blocking server startup when no token available - Add `AnyEnvVar` variant to `RequirementType` enum for HAND.toml compatibility - Write daemon logs to `~/.librefang/daemon.log` in addition to stderr
…lient_id, base_info) iLink sendmessage requires from_user_id (empty string), client_id (random UUID), and base_info.channel_version to deliver messages. Without these fields iLink returns 200 OK but silently drops the message.
This was referenced Mar 24, 2026
houko
pushed a commit
that referenced
this pull request
Jun 11, 2026
The WeChat sidecar's QR login encoded the iLink `qrcode` field into the dashboard QR canvas. But `qrcode` is only the opaque status-poll key — the payload the WeChat app decodes on scan is `qrcode_img_content`. Encoding the poll token makes WeChat render the QR as a plain-text string rather than a login prompt. The pre-migration in-process Rust adapter surfaced `qrcode_img_content` as the QR payload (the original #1560 / #1572 fix: "use iLink qr_url so WeChat can recognise the scan"). The sidecar migration (#5421) dropped that field and fell back to encoding the token, re-introducing the exact bug #1572 had fixed. `_qr_login` now reads `qrcode_img_content` and emits it as the `qr_ready` payload, falling back to the token with a WARN only if iLink omits the field; the `qrcode` token still drives status polling. Tests: updated the happy-path assertion to require `qrcode_img_content`, added a degraded-fallback case; full sdk/python suite 1874 passed.
houko
added a commit
that referenced
this pull request
Jun 11, 2026
…annable (#6086) * fix(channels/wechat): encode qrcode_img_content so the QR is scannable The WeChat sidecar's QR login encoded the iLink `qrcode` field into the dashboard QR canvas. But `qrcode` is only the opaque status-poll key — the payload the WeChat app decodes on scan is `qrcode_img_content`. Encoding the poll token makes WeChat render the QR as a plain-text string rather than a login prompt. The pre-migration in-process Rust adapter surfaced `qrcode_img_content` as the QR payload (the original #1560 / #1572 fix: "use iLink qr_url so WeChat can recognise the scan"). The sidecar migration (#5421) dropped that field and fell back to encoding the token, re-introducing the exact bug #1572 had fixed. `_qr_login` now reads `qrcode_img_content` and emits it as the `qr_ready` payload, falling back to the token with a WARN only if iLink omits the field; the `qrcode` token still drives status polling. Tests: updated the happy-path assertion to require `qrcode_img_content`, added a degraded-fallback case; full sdk/python suite 1874 passed. * test(channels/wechat): add qrcode_img_content to unrelated QR test mocks Three tests that exercise different failure/edge paths all used a mock iLink response without `qrcode_img_content`, causing the fallback WARN introduced alongside the fix to fire spuriously on every run. Each affected test now uses a realistic response that matches the happy path, so the warning stays silent unless the field is genuinely absent. --------- Co-authored-by: Evan <[email protected]> Co-authored-by: Claude <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
qrcode_img_content(full URL) to generate the QR code instead of the raw token string, so WeChat can properly recognise the scanfrom_user_id,client_id, andbase_infofields to iLinksendmessagerequest — without these iLink returns 200 OK but silently drops the messagebot_tokenbut backend field isbot_token_env, causing token not to persist after QR login~/.librefang/workspaces/agentsinstead of~/.librefang/agentsallowedHoststotrueto allow all hosts (supports Cloudflare Tunnel and custom domain access)just dashandjust apinow runpnpm installbefore starting~/.librefang/daemon.login addition to stderrcommon.retryandAnyEnvVarrequirement typeWeChat QR Login
Scan the QR code with a WeChat account bound to a +86 phone number. After successful login, the bot token is saved to
~/.librefang/secrets.envand the adapter will use it on subsequent restarts without requiring another scan.How to use
Test plan
secrets.envafter successful scanjust dash/just apiauto-install dependenciesworkspaces/agentspath