fix(interceptors): tolerate nullish handlers in syncHandlerEntries - #11118

🏄

Fixes #11114

Problem

syncHandlerEntries() reads handlers.length before checking that handlers exists, so assigning a falsy value to the public handlers array makes every subsequent request throw:

axios.interceptors.request.use(config => config);
axios.interceptors.request.handlers = null;
await axios.get('https://example.com');
// TypeError: Cannot read properties of null (reading 'length')

clear() has always guarded with if (this.handlers), and utils.forEach returns early on nullish input, so a falsy handlers array was a tolerated state on v1.19.0. This is a regression from #11087 (merged, unreleased).

Fix

Three reads were unguarded, not one:

• syncHandlerEntries — the else if (handlers.length !== ...) branch and the trailing internals.handlersLength = handlers.length. Both now use a countHandlers() helper that treats nullish as an empty stack.
• trimHandlers — returns early instead of dereferencing.
• the forEach finally block — internals.handlersLength = this.handlers.length had the same problem and now goes through the same helper.

Fixing only syncHandlerEntries leaves the finally block throwing on the way out of the first forEach, so both paths are covered.

Tests

8 cases, parametrized over null and undefined:

• forEach is a no-op rather than throwing
• a repeated forEach stays safe — this takes the handlers === handlersRef branch, which is where the stack trace in the report actually lands, and it isn't reached by a single call
• eject does not throw
• the manager recovers once handlers is restored to an array

All 8 fail on v1.x with the reported TypeError and pass with this change.

Verification

npx vitest run --project unit: 1001 passed, 1 failed. The single failure is tests/unit/adapters/fetch.test.js > should not use inherited Symbol.iterator for request headers, which fails identically on a clean checkout — unrelated to this change. npx eslint lib/core/InterceptorManager.js is clean.

Not included

The report mentions two further items from the same change, deliberately left out to keep this focused on the crash — happy to follow up on either:

• eject(String(id)) silently no-ops now that lookups go through a Map rather than an array index.
• tests/unit/core/InterceptorManager.test.js:32 indexes handlers by id, which only holds while nothing below those slots is trimmed.

No PRE_RELEASE_CHANGELOG.md entry: per AGENTS.md that file tracks user-visible unreleased changes, and this crash never shipped — v1.19.0 behaves correctly. Happy to add one if you'd prefer it recorded.

Summary by cubic

Prevents a TypeError when interceptor handlers are set to null or undefined by treating them as empty and restoring them on use(). Previously syncHandlerEntries and the forEach cleanup read .length unguarded and could crash; now both paths are safe and behavior matches prior tolerant releases.

Details

• Adds countHandlers() and uses it in syncHandlerEntries and the forEach finally block to guard nullish stacks.
• Makes trimHandlers() return early for nullish handlers.
• Updates use() to initialize a nullish handlers array to [] so adding a handler recovers the manager.
• Changes are limited to lib/core/InterceptorManager.js.

Testing and Docs

• Adds 8 unit tests covering null/undefined: forEach is a no-op, repeated forEach is safe, eject does not throw, and adding a handler after a nullish stack works.
• Suggest updating /docs/ to clarify that while handlers is public, consumers should prefer eject()/clear(); if set to null/undefined, axios treats it as empty and use() restores it.
• Semantic version impact: Patch.

^{Written for commit a56dd3c. Summary will update on new commits.}