Lodash debounce cancel() limits: what happens to an in-flight async call from the leading edge

Direct answer

When a debounced function is async and invoked with leading: true, the first call runs immediately and returns a Promise. Calling .cancel() afterward clears Lodash's internal timer and prevents any future trailing-edge invocation, but it has no effect on the Promise already returned from the leading-edge call. That Promise will resolve or reject based solely on the async work inside your function.

Your three questions, answered

1. Does .cancel() have any defined effect on a Promise returned by a leading-edge invocation that is still pending? No. Lodash's .cancel() only resets the debounce timer and clears lastArgs/lastThis. It cannot reject, resolve, or suppress a Promise that has already begun executing. The Promise settles normally.
2. Is there any documented interaction between .cancel() and the leading/trailing options that changes this behavior? No. The documentation and source confirm that .cancel() affects only invocations that have not yet happened. Because a leading-edge call executes immediately at the first trigger, it is by definition already past the point where .cancel() can intervene.
3. Is managing an AbortController outside the debounced function the intended pattern, or does Lodash offer anything built in? Lodash offers no built-in async cancellation. The intended pattern is to create an AbortController per invocation, pass its signal to your fetch or async operation, and call controller.abort() in the same place you call .cancel(). Combine this with a guard (e.g., a monotonically increasing request ID or an isCurrent flag) checked before applying any response, to prevent stale state updates.

Practical verification (quick steps)

1. Create a debounced async function: const d = _.debounce(async (query) => { /* fetch */ }, 300, { leading: true })
2. Trigger it once: d('search'); note the returned Promise.
3. Immediately call d.cancel() while the fetch is pending.
4. Wait for the leading Promise to settle; confirm it resolves/rejects as if .cancel() never ran.
5. Wait past the debounce interval; confirm no second invocation fires (trailing edge was cancelled).

Version assumption: This behavior matches Lodash 4.x (4.17.x series), which has been stable since its introduction. Confirm the installed version if you are on a custom build or legacy project.

Caution: .flush() has the opposite risk—it immediately invokes a pending trailing call, which can start new async work you may not want during teardown. If you use maxWait, a trailing invocation may be scheduled mid-burst; .cancel() still only prevents future invocations, never in-flight ones.

Side-effect note: AbortController aborts the network request, but other side effects (logging, cache writes) inside your async function will still run unless you check signal.aborted yourself and return early.