API move action on root node breaks account

šŸ›Bugs
1

Iā€™m building a Dynalist MCP server that lets AI assistants interact with Dynalist via the public API. While testing edge cases for move operations, I discovered that moving the root node via /api/v1/doc/edit permanently locks the entire account. Rather than rejecting the invalid request, the API accepts it and every subsequent call across all documents returns LockFail. The web client also fails to load entirely: the document sidebar says ā€œCanā€™t load documentsā€ in red, and the main pane shows the loading icon forever.

Steps to reproduce

  1. Read any document via /api/v1/doc/read to identify a child node ID.
  2. Send a move action targeting the root node, with any child as the destination parent:
{
  "file_id": "<document_id>",
  "changes": [
    {
      "action": "move",
      "node_id": "root",
      "parent_id": "<any_child_node_id>",
      "index": 0
    }
  ]
}

Expected result

The API should reject the request with an error (e.g. InvalidInput) and leave the document unchanged, consistent with how delete handles the root node (silently ignored, returns Ok, no effect).

Actual result

The entire account becomes permanently locked. Every API endpoint returns LockFail for every document. The web client fails to load entirely: the document sidebar says ā€œCanā€™t load documentsā€ in red, and the main pane shows the loading icon forever. Tested against the live API on 2026-03-13.

I checked again yesterday (3/14) and the account was able to load again. @Shida did you manually fix the corrupted account, or did it recover on its own somehow?

Environment

N/A. This is a server-side API bug, reproducible via curl from any environment.

Additional information

The delete action already handles the root node gracefully: sending action: "delete" with node_id: "root" is silently ignored and returns Ok. The move action should do the same, or return an explicit error. An invalid move request should never be able to take down an entire account.

Iā€™m now validating and rejecting root-node moves on the client side, but every other API consumer is one bad request away from a bricked account.

2

I havenā€™t touched your account. I think thereā€™s definitely going to be a couple of edge cases like these that we arenā€™t verifying correctly.

I canā€™t currently commit to a fix yet, but I will be on the lookout to collect these for when I have some spare bandwidth. Thanks for the detailed report!

1 Like