Repository navigation
doc block update on large document table fails with server-side HSF 3000ms timeout #484
Description
Summary
When updating a single block inside a large DingTalk Doc table with dws doc block update --content-format jsonml, the command can fail with a server-side HSF timeout:
HSFTimeOutException-HSF-0002
Invalid call is removed because this request is already timeout.Timeout value is : 3000
Increasing the CLI HTTP timeout, for example --timeout 120, does not help. The returned error still reports an internal 3000ms timeout, so this looks like a server-side timeout rather than a client-side wait limit.
I have intentionally redacted the real DingTalk document URL, nodeId, blockId, dashboard URL, and business wiki URL from this public issue. I can provide a private reproducible sample if needed.
Environment
- dws version:
v1.0.39 - edition:
open - build:
2026-06-18T06:12:02Z - commit:
91f44a1 - OS: macOS 15.7.3, arm64
Reproduction Shape
The failing operation is a narrow block update against one paragraph block in a large document table:
dws doc block update \
--node <DOC_NODE_ID> \
--block-id <BLOCK_UUID> \
--content-format jsonml \
--element '["p",{"spacing":{},"uuid":"<BLOCK_UUID>"},["span",{"data-type":"text"},["span",{"data-type":"leaf"},""]],["a",{"href":"<TARGET_ANCHOR_URL>"},["span",{"data-type":"text"},["span",{"data-type":"leaf"},"event_param说明"]]],["span",{"data-type":"text"},["span",{"data-type":"leaf"},""]]]' \
--format json \
--verbose \
--timeout 120Actual response:
{
"error": {
"category": "api",
"code": 1,
"message": "HSFTimeOutException-HSF-0002\nerror message : Invalid call is removed because this request is already timeout.Timeout value is : 3000",
"reason": "business_error",
"server_error_code": "systemError",
"server_key": "doc"
}
}Expected Behavior
For a single-block update, one of the following would be helpful:
- The server-side timeout respects the CLI
--timeoutvalue, or exposes a separate configurable timeout for this operation. doc block updateuses a more precise document/block update path that does not require processing enough of the large document/table to hit the 3s HSF timeout.- If this is an upstream doc-service limitation, the CLI returns a clearer error and guidance such as "large table block update may exceed upstream 3s HSF timeout; use smaller-scope API / manual edit / retry later".
Notes
The write result was verified by reading the document back in markdown mode. After the timeout, the target block remained unchanged, so this was not just a client-side timeout after a successful write.
Activity
Dino1010 commentedon Jun 23, 2026
Additional diagnostic info for maintainers:
2132f5ca17821954249277708e0874docsystemError3000msThis trace was captured from the redacted reproduction described above. No internal DingTalk document URL, nodeId, dashboard URL, or business wiki URL is included here.
dzshzx commentedon Oct 14, 2026
Another data point for the same server-side
HSFTimeOutException(3000 ms), this time on a whole-document overwrite rather than a single block update, on a newer CLI.4cd5d05), editionopen, Linux x86_64dws doc update --node <DOC> --content-file <file> --content-format jsonml --revision <n> --mode overwrite --format json --yesObserved on 2026-10-14 (times from the local
dws.log):update_documentdurationbusiness_error(HSF timeout); a read-back right after showed the document unchanged--revision)business_error(HSF timeout); document still unchangedIn the same run, a ~42 KB document was overwritten in 0.5 s. So the 3 s server budget seems to hold for small documents, but a document of a few hundred KB lands close enough to it that the outcome depends on server load at that moment. That fits the original report:
--timeouton the client has no effect.On our side, we keep each main synchronized document's normalized projection under a size budget so it stays clear of this limit (the document in this report is a linked copy, which has no such budget yet), and we treat an HSF timeout as an unknown outcome: read back, then retry once only if the revision and content are unchanged. It would help if either:
update_document/ block updates scaled with payload size, or were longer than 3 s; or