[Bug] ZCode 3.10.1 WeChat Bot: Replies Generated but Never Delivered — Silent Outbound Failure (Similar to #200)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Bug Description
WeChat bot in ZCode 3.10.1 receives and processes messages correctly, but generated replies are never delivered back to WeChat. The failure is completely silent — no error messages, no log entries for the send attempt, and no visible indication of failure to the user.
Impact Severity: HIGH — Core Bot Functionality Broken
- WeChat bot is completely non-functional for outbound communication
- Users see "typing…" indicator then nothing arrives
- No error feedback makes debugging extremely difficult
- Affects all WeChat bot users on ZCode 3.10.1
Detailed Report
Environment
| Component | Value |
|---|---|
| ZCode Version | 3.10.1 |
| Platform | Linux AppImage |
| OS | Ubuntu 26.04 |
| Plan | GLM Coding Plan (GLM-5.3) |
| Bot Type | WeChat bot |
| Connection Mode | Long-polling |
| Reply Mode | Standard |
Reproduction Steps
- Bind WeChat via QR code → Succeeds, status shows "long-polling running"
- Send any text message from WeChat to the bot
- Observe behavior:
- WeChat shows "typing…" indicator for a few seconds
- Then nothing — no reply ever arrives
- Check ZCode desktop:
- Message was received ✅
- Task was created in bound workspace ✅
- Agent reply was generated (status: completed) ✅
- Reply was NOT delivered to WeChat ❌
- Test bot commands:
/statusand other commands also get no reply
Expected Behavior
- Reply should be delivered back to WeChat after agent completes
- User should see the response in their WeChat chat window
- If delivery fails, there should be a visible error in logs or UI
- All bot commands should receive responses
Actual Behavior
User Experience (WeChat Side):
User sends: "测试" (test)
↓
Bot shows: "typing..." (3-5 seconds)
↓
Result: [EMPTY] — nothing arrives, no error, no failure message
System Behavior (ZCode Side):
✅ Step 1: Message RECEIVED
Log: 00:54:39 [bots] provider callback provider=weixin ... text=测试
✅ Step 2: Task DISPATCHED
Log: 00:54:40 [zcode-task-service] sendPrompt started
✅ Step 3: Reply GENERATED
Log: 00:54:58 snapshot {assistantMessages:3, contentChars:161, completed}
❌ Step 4: Reply DELIVERED ← THIS STEP IS MISSING
Log: (no reply-send log line, no error, nothing after this)
Critical Observation:
There is absolutely no log entry for the reply send operation. The system generates the response successfully but never attempts (or never logs) the outbound delivery to WeChat.
Log Evidence
ZCode Main Logs (~/.zcode/v2/logs/2026-08-31.log):
00:54:39 [bots] provider callback provider=weixin ... text=测试 ("test")
↑ Message received from WeChat
00:54:40 [zcode-task-service] sendPrompt started
↑ Dispatched into task queue
00:54:58 snapshot {assistantMessages:3, contentChars:161, completed}
↑ Agent finished generating reply
[ NOTHING AFTER THIS POINT ]
↑ No send attempt, no error, no delivery log
CLI Logs (~/.zcode/cli/log/*.jsonl):
Result: zero bot-related entries all day
↑ The reply send operation never executes locally
Troubleshooting Attempted
| Attempt | Result |
|---|---|
| Full GUI restart (including tray) | ❌ No effect |
Removed stale webRemoteControlExternalRelayDevice binding |
⚠️ Drop warnings gone, but replies still lost (not the relay cause) |
| Rebound bot session workspace | ❌ Routing works fine, replies still lost |
| Deleted bot + re-scanned | ❌ Brand-new cloud bot account (704136178063@im.bot), fresh credentials, identical reproduction |
Conclusion from Testing:
"The outbound reply path looks broken in 3.10.1 — inbound → task → agent all work; only the final delivery to WeChat is silently lost."
— Jiamo.im
Root Cause Analysis
Diagnosis: Outbound IPC Dispatch Bug
As identified by moderator review:
"You've hit an outbound IPC dispatch bug as it seems: the task completion handler generates the response but fails to trigger the weixin provider outbound delivery hook."
— Roman | Z (Volunteer/Mod)
Likely Location of Failure:
┌─────────────────────────────────────────────────────────────┐
│ MESSAGE FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ WeChat Server │
│ │ │
│ │ ① Message Received ✅ │
│ ▼ │
│ ZCode Inbound Handler │
│ │ │
│ │ ② Create Task ✅ │
│ ▼ │
│ Task Service / Agent ││ │ │
│ │ ③ Generate Reply ✅ │
│ ▼ │
│ Task Completion Handler │
│ │ │n│ │ ④ Trigger Provider Send Hook ❌ BROKEN HERE │
│ │ (weixin outbound delivery never fires) │n│ ▼ │n│ [GAP] ← Reply sits here, never sent │n│ │n│ WeChat Client (User's Phone) │n│ │ │n│ │ ⑤ Receive Reply ❌ NEVER ARRIVES │n│ │
└─────────────────────────────────────────────────────────────┘
Possible Technical Causes:
1. Missing Event Emitter / Callback Registration
// Current (possibly broken):
taskService.on('complete', async (task) => {
const reply = task.response;
// Missing: await weixinProvider.send(reply);
// Or: event not registered for weixin provider
});
2. Provider-Specific Dispatch Logic Missing
- Task completion handler may have generic logic that doesn't cover WeChat's specific API requirements
- WeChat long-polling mode may need different delivery mechanism than other providers
3. Async/Await Gap or Unhandled Promise
// Possible bug pattern:
taskService.on('complete', (task) => {
weixinProvider.send(task.response); // Missing 'await'!
// Or: Promise not returned, error swallowed
});
4. Configuration/Registration Issue in 3.10.1
- WeChat provider may not be properly registered in the outbound dispatcher
- Could be a regression introduced in 3.10.1 (worked in earlier versions?)
5. Silent Error Swallowing
- Send attempt may fail with caught exception that's logged nowhere
- Or send may throw in unobserved promise chain
Related Issues
Similar to: #200 (Referenced by Reporter)
- This appears to be the same class of bug as previously reported issue #200
- Both involve outbound delivery failures where inbound + processing work fine
- Linking this report to #200 for engineering team correlation
Proposed Fix
Immediate Investigation Required:
-
Trace Task Completion Code Path
- Find where
taskServiceemits 'complete' event - Verify WeChat provider's send handler is registered
- Check if provider-specific dispatch logic exists for
weixin
- Find where
-
Add Logging at Critical Points
// Add temporary debug logging: taskService.on('complete', async (task) => { console.log('[DEBUG] Task complete, provider:', task.provider); console.log('[DEBUG] Response length:', task.response?.length); try { await providers[task.provider]?.send(task.response); console.log('[DEBUG] Send success'); } catch (err) { console.error('[DEBUG] Send failed:', err); // Currently missing! } }); -
Verify Provider Registry
- Check if
weixinprovider is in the active providers map - Confirm
send()method exists and is callable - Test with mock WeChat delivery endpoint
- Check if
-
Check for Regression
- Identify if this worked in 3.9.x or earlier
- Git bisect between working version and 3.10.1 to find breaking change
Workarounds (For Users Until Fix)
Current Status: No Known Workaround
All attempted workarounds by reporter failed:
- ❌ Restart doesn't fix
- ❌ Rebinding workspace doesn't fix
- ❌ Fresh bot account doesn't fix
- ❌ Removing stale bindings doesn't fix
Potential (Untested) Workarounds:
- Downgrade to earlier ZCode version (if 3.9.x worked)
- Use different connection mode (if available: webhook instead of long-polling)
- Switch to different bot platform temporarily (Discord, Slack, etc.)
Impact Assessment
| Metric | Value |
|---|---|
| Feature Affected | WeChat bot outbound messaging (100% broken) |
| ZCode Versions Affected | 3.10.1 (confirmed); possibly others |
| Platforms Affected | Linux (confirmed); likely all platforms |
| Plans Affected | GLM Coding Plan (and likely others) |
| Bot Commands Affected | All (/status, etc.) — same silent failure |
| Error Visibility | NONE — completely silent, no logs |
| User Impact | CRITICAL — bot appears broken to end users |
Additional Notes
Why This Is Particularly Problematic:
-
Silent Failure = Impossible to Self-Diagnose
- Users have no indication what went wrong
- No error codes, no error messages, no log entries
- Requires deep system knowledge to even identify the failure point
-
Affects Production Bot Deployments
- WeChat bots are often used for customer service, notifications, automation
- Silent failure means users don't know their bot is broken
- Could miss important interactions for hours/days before noticing
-
Debugging Quality Is Excellent
- Reporter provided textbook-quality bug report
- Clear reproduction steps, environment details, log evidence
- Already ruled out common causes (restarts, rebinding, fresh credentials)
- This should make fixing relatively straightforward for engineering team
Moderator Assessment:
"This is a textbook bug report."
— Roman | Z (Volunteer/Mod)
Discord Thread Reference
Original Report: Discord community thread
Reporter: Jiamo.im
Moderator Review: Roman | Z (Volunteer/Mod) — confirmed as IPC dispatch bug, requested GitHub submission
Related Issue: #200 — similar outbound delivery failure
Submitted by: Roman Galaxys10 (Roman) — Z.ai Volunteer Ambassador
Discord: bignavi_x
GitHub: romangalaxys10-spec
Source: Discord Community — User: Jiamo.im
Submitted With Permission: User explicitly requested submission on their behalf
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the taskService completion path and the weixin provider registration and send handler; compare the flow with related issue #200. Reproduce using long-polling with a text message or /status command, then trace whether completion reaches outbound delivery. Done means replies arrive in WeChat and delivery failures produce log or visible error feedback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100