Check your version and whether the failing tests ran at the same time. n8n 2.42.7, released October 12, 2026, fixes a bug where credential tests running concurrently could share one temporary node type registry and fail with 'Node not found'. That error alone doesn't tell you the secret is bad. So before anyone rotates an API key, re-issues an OAuth app or opens a ticket with a vendor, rule out the race condition. That can save hours of chasing a problem that lives in n8n, not in your integration.
What changed in 2.42.7
The release notes, under the heading '2.42.7 (2026-10-12)', list a core fix: 'Keep concurrent credential tests from sharing one node type registry (#40783)'. The same release also includes an unrelated fix for resuming tool calls on deferred tools that a skill loaded (#40747). That second change touches the AI tooling side and isn't connected to credential testing.
The backport PR predates the release, so this isn't a newly discovered defect. What's new today is a stable patch that carries the fix. No mandatory upgrade deadline or end-of-support date is attached to it.
Why the error looked like a bad credential
Some credential tests in n8n are request-based. To run one, n8n builds a temporary node definition, registers it, runs the test request through a workflow, and then cleans up. Before the fix, those temporary definitions lived in a shared registry. Per the PR description, two overlapping tests could overwrite each other's definitions, and one test's cleanup step could delete a definition the other test still needed. The surviving test then failed with 'Node not found'.
From the admin's chair, that looks like a credential test that failed, and it's easy to read it as a wrong secret or an expired token. The underlying cause was a collision between tests that happened to overlap. Because it depends on timing, it won't necessarily show up every time.
The fix is structural. In the PR's words: 'Each run now gets its own registry (createMockNodeTypes() per call) and passes it to its Workflow. No shared state, so the finally cleanup is gone.' With no shared registry, there's nothing for parallel tests to trample.
What this bug is not
- Not a credential leak. Nothing in the release or the PR describes secrets being exposed.
- Not a general workflow outage. The defect is in the credential-test path, not in normal workflow execution.
- Not a reason to jump major versions. The fix ships as a patch on the 2.42 line.
Safe troubleshooting steps
Prerequisites: admin access to your n8n instance, a non-production or staging environment for testing the patch, and a current backup of your n8n database and encryption key before any upgrade. These steps assume you're already on the 2.42 release track.
- Record the installed n8n version and the exact error text from the failed credential test. Note the time of the failure.
- Check whether other credential tests were running at the same moment, for example several people configuring integrations at once or an automated setup script testing credentials in parallel.
- Retest the affected credential on its own, with no other tests running. A pass in isolation is consistent with the concurrency bug and gives you no reason to suspect the secret.
- If you're on a 2.42.x version earlier than 2.42.7, deploy 2.42.7 to a test environment first and confirm your existing workflows and credentials behave as expected.
- Schedule a controlled upgrade of production to 2.42.7 after the test environment checks out, with the backup from the prerequisites ready for rollback.
- After the upgrade, retest the credentials that previously failed. If one still fails on its own, this race condition is no longer the likely explanation, so record the new error text and diagnose that error before deciding anything. Rotate or re-issue a secret only once the diagnosis actually points at the credential.
To confirm the version on a self-hosted install, run the CLI inside the environment where n8n runs. On a Docker deployment, swap in your container name:
n8n --version
# Docker
docker exec <your-n8n-container> n8n --versionThe business takeaway
An error message that blames the wrong layer is expensive. Teams can burn a morning resetting secrets, waiting on a SaaS vendor's support queue, or delaying a client integration go-live over a problem that a patch release already fixed. A short habit helps: record the version, record the exact error, and check for overlap before you touch credentials. Upgrades stay on your schedule, tested first, rather than becoming a fire drill.