DeepSeek Harness web_search abort and web_fetch pipe loss

**DeepSeek Harness (DSH)'s web_search and web_fetch have two defects that are easily misjudged as "network jitter", and what they share is that the result is already wrong on the write side: the search one is that one failed sub-query voids the whole batch—the fan-out uses a shared cancel signal, so any failed query cancels the others in the same batch, and the later collection logic still throws the first error, so results that "already succeeded and were already paid for on a per-call service" are discarded along with it; the fetch one is that consecutive pipes in a table cell get collapsed into one—Markdown tables require pipes to be escaped character by character, but the implementation uses "replace a run of consecutive pipes as a whole", so the semantics of code expressions are quietly changed and it cannot be recovered from the Markdown result side (three different numbers of pipes render to the same shape) (#8794, #9630).

DSH plugin one failed query voids the whole batch: the fan-out is dragged down by a shared cancel signal

One-line conclusion: parallel sub-queries share one cancel signal, so any failure aborts the rest; even though the collection uses an "await all" form, it still throws the first error afterward, so the result-merge step never runs—the tool returns only one error and the successful results are all lost. The symptom is "a multi-query search reporting only one error and no results at all" (#8794).

DSH plugin diagnosis: two checks, one on shape and one on the bill

1. Look at the return shape: one call carrying several sub-queries returns only one error and no result entries—that is this entry; if it returns partial results and labels one sub-query as failed, that is a different (partial-success) shape (#8794).
2. Look at the billing record (very telling): on a per-call search service, each sub-query is an independent billed round. If your backend shows a charge count equal to the number of sub-queries you submitted while the tool returns only an error, the results were discarded—you paid but got nothing (#8794).

DSH plugin three-step handling and fix direction

1. Reduce the number of sub-queries (temporary workaround): send only one query at a time, turning "batch search" into several single queries—trading concurrency for availability (#8794).
2. Fix (given in the discussion, three changes together): remove the shared abort; return the successful queries' results one by one and label the failed one by name in the result; fail as a whole only when all fail (#8794).
3. Verify: build a case where "one query is bound to fail and the other two are bound to succeed" and expect the return to show two successful results plus one failure label, rather than a single whole error (#8794).
4. Note what it means for cost: this is not just an experience problem—on a per-call service, a whole-batch void means money wasted, so the fix priority should be higher than for an ordinary UI defect (#8794).

DSH plugin table pipes get collapsed: Markdown escaping written as "replace a run"

One-line conclusion: when rendering a cell, a "replace a run of consecutive pipes as a whole" regex squashes || into |, while GFM requires pipes to be escaped character by character—so the code expression first||last is written as first|last and the meaning changes; worse, this damage cannot be recovered from the Markdown result side (|, ||, ||| all render to the same shape). The symptom is a successful fetch with no truncation, but content quietly rewritten (#9630).

DSH plugin three-step confirmation and handling

1. Confirm the diagnosis: fetch a page with a code table (a ||-style expression in a cell) and check whether the pipes in the converted Markdown decreased; at the same time confirm the request succeeded and the result was not truncated—"successful but rewritten" is this entry's fingerprint (#9630).
2. Temporary workaround one: fetch the raw content rather than the rendered table (for example a source page or an API return), bypassing this conversion path (#9630).
3. Temporary workaround two: don't let the model judge code based on that table, and double-check against the original page when needed (#9630).
4. Fix: change "replace a run" to per-character escaping—the reporter provides a minimal patch that can be extracted on its own (#9630).
5. Verify: refetch the same page and confirm the number of pipes in the Markdown matches the original page (|| is still \|\|, two characters rather than one) (#9630).

DSH plugin troubleshooting notes

The key point for both is "first tell apart a failure of the search/fetch itself from a result that got changed in the conversion step". Seven points:

1. For the search entry, check shape + check the bill; using both together is most accurate (#8794).
2. "Only one error, zero results" ≠ "really found nothing": in a multi-sub-query scenario, suspect a whole-batch void first (#8794).
3. The correct semantics of fan-out is "each sub-query succeeds or fails independently", not "all succeed or all fail" (#8794).
4. Write the cost impact into your conclusion: a whole-batch void on a per-call service is real money (#8794).
5. For the fetch entry, "successful but rewritten" is more dangerous than an error: it does not put you on your guard (#9630).
6. The damage is irreversible: don't expect to fix the pipes at a downstream parse stage—the information is lost at conversion time (#9630).
7. State the fix status honestly: both are unfixed in the versions the discussions refer to (around 0.2.1-alpha.2); the search entry's fix (drop the shared abort + partial-success semantics) and the fetch entry's patch are both unmerged, so for now only user-side workarounds like "split into single queries" and "fetch raw content" exist.

When investigating search and fetch problems, it is easy to be led astray by the "network" direction. If you want to confirm the "environment" layer first—for example whether a given search/fetch plugin was ever installed and how many versions—instead of typing commands everywhere, use a visual plugin marketplace such as DSH Plugin Hub: the installed list, install/uninstall history, and system logs are all in one panel.

Source: Discussion #8794, Discussion #9630.