DataTables serverSide request cancellation and stale response ordering

Direct answer

Yes. A custom ajax function can reliably discard out-of-order responses using only documented DataTables APIs. There is no DataTables-specific request-timeout setting; the documented mechanism is to pass a timeout value inside the settings object that your ajax function forwards to jQuery.ajax.

Discarding stale responses with a request token

When ajax is a function, DataTables invokes it with (data, callback, settings). You can keep a counter outside the function, increment it on every call, and attach it to the outgoing payload. In the success handler, compare the token in the response with the latest token you sent; only call the DataTables callback when the response is current.

let latestRequestId = 0;

$('#example').DataTable({
  serverSide: true,
  ajax: function (data, callback, settings) {
    const requestId = ++latestRequestId;
    data.requestId = requestId;

    $.ajax({
      url: '/api/data',
      data: data,
      dataType: 'json',
      timeout: 5000,
      success: function (json) {
        if (requestId === latestRequestId) {
          callback(json);
        }
      },
      error: function () {
        if (requestId === latestRequestId) {
          callback({ data: [], recordsTotal: 0, recordsFiltered: 0 });
        }
      }
    });
  }
});

This uses only the documented ajax function signature and standard jQuery.ajax options. It does not depend on undocumented internals. Network reordering is handled correctly: a late response with an older token is ignored, while the newest response always carries the highest token and is accepted.

Per-request timeout

DataTables defines no dedicated timeout option. In the function form above, timeout: 5000 is passed directly to jQuery.ajax, which applies it to that single request and overrides any global $.ajaxSetup timeout for the call. If the request is aborted or times out, jQuery triggers the error path. To prevent DataTables from raising a default alert on that abort, set $.fn.dataTable.ext.errMode = 'none' and observe the xhr event for status 0.

Version assumptions and verification

The token and timeout patterns are stable across DataTables 1.10.x, 1.11, and 2.x because they rely on the ajax function contract, not on debounce internals. The searchDelay default differs by version—200 ms in 1.10.x/1.11 and 0 ms in 2.x—so confirm the running version with $.fn.dataTable.version before tuning debounce behavior.

• Add a server-side delay for the first request and type again; verify only the second response renders.
• Set timeout to a small value and confirm the xhr event fires with status 0 while the table remains stable.
• Check $.fn.dataTable.version against the documented searchDelay default for that release.

When this does not apply

If your ajax option is currently a string URL or plain object and cannot be replaced by a function, the client-side token approach is not available without rewriting the entire ajax configuration. Are you able to switch the ajax option to a function, or is it fixed by an existing integration?