Two binding paths store different DingTalk ID types: - OAuth binding stores staffId (resolved via unionId→userId at auth time) - Code binding stores senderId ($:LWCP_v1:$... format from bot message) DingTalk Stream API senderId != OAuth openId (different encodings), so primary lookup by senderId always missed OAuth-bound instances, requiring a fallback every time. Reverse the lookup order: try senderStaffId first (direct hit for OAuth binding), fall back to senderId (code binding). Also add MAX_RESPONSE_BYTES cap to httpPostJson — previously uncapped unlike the DingTalk API helpers which already had the 256KB guard. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| agent-service | ||
| audit-service | ||
| auth-service | ||
| billing-service | ||
| comm-service | ||
| inventory-service | ||
| monitor-service | ||
| notification-service | ||
| ops-service | ||
| presence-service | ||
| referral-service | ||
| version-service | ||
| voice-agent | ||
| voice-service | ||