dsh bot bridges: Feishu, WeChat and QQ with DSH plugin

A message from Feishu, WeChat or QQ reaches dsh bot through a DSH plugin bridge and at least two other hands. I followed one test message from the platform to the reply and wrote down what it looked like at every hop. The same trace tells you which component to inspect when the bot goes silent.

What a message looks like before any DSH plugin touches it

The platform emits a signed event with identifiers, and that event is the only thing the bridge is allowed to trust.

A Feishu message event arrives as JSON with an event id, a message id, a chat id, a sender id, the text and a timestamp. The signature sits in a header, computed over the raw body with the app secret. None of these fields is optional, because each one is used later to route and deduplicate.

WeChat and QQ deliver a similar payload over a long connection, with different field names and a different authentication step. The bridge's job is to erase those differences before the bot sees anything. A normalized envelope is what makes one bot workable across platforms.

A break here is easy to recognize because the platform keeps its own delivery record. If the callback log is empty, the platform never sent the event, and no amount of bridge configuration will help. A 4xx response or a signature failure usually appears in the same log with a reason code.

The first evidence to collect is therefore the platform's view, not the bot's answer. That view includes whether a retry happened and what response the endpoint returned. Anything the bridge claims after that can be checked against it.

Inside the DSH plugin bridge, the event becomes bot input

The bridge verifies, normalizes and deduplicates, and its log line is the proof that an event entered your system.

The bridge receives the event through a webhook endpoint or a persistent connection, then verifies the signature against the app secret. It looks up which bot instance should receive the message before it changes anything. Rejecting early is cheaper than debugging a malformed turn later.

What comes out is a small envelope: source platform, conversation id, sender, text, reply target, timestamp and a dedupe key. The dedupe key matters because platforms retry, and a retried event should not become two turns. The envelope is also where attachments and mentions are reduced to something the bot can read.

A healthy bridge writes one line per accepted event with the event id, the target bot and the conversation. A break leaves either no inbound line at all or a line that ends in a signature or format error. Those two failures point at different fixes, which is why the log line should be specific.

DSH plugins that act as bridges are separate installs from the bot itself, so their version is worth recording. A bridge copied from DSH Plugin Hub today may behave differently from one installed six months ago. The log format and supported protocol are the first things to compare after an upgrade.

The DeepSeek Harness plugin hands a clean turn to dsh bot

The bot receives a turn, not a platform event, and a missing turn id means the handoff failed.

By the time the bot sees the message, the envelope has become a turn with a session key. The key usually combines platform, conversation and sender, so two people in one group do not share context by accident. Getting that key wrong produces replies that look intelligent and address the wrong person.

The bot then applies its own layers: memory recall, tool permissions and the approval gate. A message that asks for an out-of-bounds action may pause instead of answering, which is correct behavior rather than a bridge failure. The turn id is what ties all of those decisions to the original event.

Evidence of a successful handoff is a turn id, a session id and an approval state in the bot log. A break shows up as an envelope that arrives but never becomes a turn, or a turn that waits forever for approval. The first case belongs to the bridge interface, and the second belongs to policy.

When the bot log shows nothing, the model is not the suspect yet. Check the bridge's outbound handoff and the bot's listener before touching prompts. That order prevents the common mistake of rewriting a system prompt to fix a delivery problem.

The reply takes the same DeepSeek Harness plugin path back

A reply is a second message with its own identifiers, and the platform's message id is the receipt.

The model produces text, and the bot wraps it in a reply object with the target conversation and the originating message. The bridge converts that object into the platform's format, including mentions and length limits. Markdown often has to be downgraded, because a platform that renders plain text will show asterisks instead of emphasis.

The bridge then calls the platform API and receives a response containing a message id or an error code. That response is the only proof the user can see the answer. A log line that says the reply was sent without a platform id is a hope, not evidence.

A break on this hop is specific: an expired token, a missing permission scope, a rate limit, or a message longer than the platform accepts. Each produces a different status code, and each fix is different. Chunking a long answer is usually the answer when the text itself is valid.

I close the trace when the platform reports a message id for the reply. Anything less means the loop is still open, even if the bot log looks cheerful. The id also gives you something to search when a user says the answer never arrived.

Reading the evidence a DSH plugin hop leaves behind

One message id traced through every log is worth more than four dashboards that disagree.

The trace starts with the message id from the platform and follows the same event through each component. Keep the ids together in one note: event id, bridge line, turn id and reply message id. When one of them is missing, the break sits between the previous id and the missing one.

1. Send one message from a test account and record the platform message id.
2. Find the bridge line for that id and confirm the signature result.
3. Find the turn id and the session key in the bot log.
4. Check the approval state before assuming the model failed.
5. Find the platform response for the reply and its message id.
6. Stop the bridge once and confirm the platform records a failure rather than silence.

A silent failure is the one worth fixing first, because it hides every later problem. If stopping the bridge loses messages without a platform-side error, delivery guarantees are weaker than the design assumes. Retries and deduplication should be tested together, since a retry storm is the usual cost of fixing silence.

The chain is stable even when the platforms are not. Versions, field names and permission models change, but the order of evidence does not. Trace the message, name the hop, and only then change a setting.