hailin 5a66f85235 fix(dingtalk): senderStaffId-first routing + bridge response size cap ... 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>		2026-03-08 22:48:03 -07:00
..
gateway	feat(dingtalk): OAuth one-tap binding + voice tool + public Kong route	2026-03-08 09:09:00 -07:00
openclaw-bridge	feat(dingtalk+bridge): event-based agent reply + greeting on binding	2026-03-08 13:18:52 -07:00
services	fix(dingtalk): senderStaffId-first routing + bridge response size cap	2026-03-08 22:48:03 -07:00
shared	feat(dingtalk): unified DingTalk bot router with binding flow	2026-03-08 08:12:27 -07:00