SurrealDB client read timeout leaves server-side query running

Answer the question first

Short answer: A client‑side read or request timeout does not automatically abort the server‑side query. The server usually keeps running until the statement finishes, an explicit server‑side cancellation is issued, or a server‑configured limit is hit.

What is confirmed

• SurrealQL offers CANCEL TRANSACTION to stop an explicit multi‑statement transaction, but no equivalent statement exists for a single long‑running query.
• SDKs expose a timeout field that terminates the client’s wait or closes the TCP connection, but the protocol does not send a cancellation message to the server.
• Server‑side query cancellation can be configured via the server’s config.json (e.g., max_query_time), or by invoking CANCEL TRANSACTION if the query is wrapped in a transaction.

Likely explanation

When a client times out, the client library usually:

1. Stops reading from the socket.
2. Closes the connection.

Because the HTTP/WebSocket protocol is stateless, the server receives a broken connection but has no built‑in mechanism to detect this until it attempts to send a response. Most SurrealDB server versions keep processing the query in the background; the result is simply discarded when the client disconnects.

Steps to verify for your setup

1. Check your SDK’s timeout setting. For example, in the JavaScript SDK you can set:

   const client = new Surreal({
     url: "ws://localhost:8000/rpc",
     timeout: 5000 // milliseconds
   });
   

2. Run a deliberately long query. In a separate terminal, start the SurrealDB server with a log level that includes query start/finish events (e.g., log_level: "debug" in config.json).
3. Trigger the client timeout. Observe whether the client reports a timeout error and whether the server log shows the query finishing or being interrupted.
4. Optionally, wrap the query in a transaction:

   BEGIN;
   SELECT * FROM big_table;
   COMMIT;
   

   Then, after the client times out, run CANCEL TRANSACTION from another session to see if the server stops execution.

What to ask next

To give a precise recommendation you’ll need to know:

• Which SurrealDB server version you are running (the behavior changed after 1.5).
• Which SDK and its timeout parameter you are using.

Providing that information will let us pinpoint whether server‑side query cancellation is possible via configuration or only via CANCEL TRANSACTION inside a transaction.

Practical takeaway

Until you confirm that your server version supports a server‑side query timeout, treat client timeouts as a client‑only abort. If you need to guarantee that long queries do not consume server resources, configure max_query_time in config.json or wrap the query in a transaction and cancel it explicitly.