n8n 2.35.3: The QA Upgrade Checklist Before You Deploy

n8n 2.35.3 shipped on August 14, 2026, and most teams I talk to will not test it at all. They will click upgrade, restart the container, and discover three days later that a Google Ads sync stopped pulling data because the node silently migrated from the sunset v21 API to v25. A patch release that ships an API migration is exactly the kind of change that breaks automation without a single error in the logs. This is the QA upgrade checklist I run before any n8n release touches a production workflow.

Table of Contents

• What n8n 2.35.3 Actually Changed
• Why a Patch Release Still Needs a QA Gate
• The Upgrade Risk Assessment
• The 7-Step QA Upgrade Checklist
• Testing Triggers, Branches, and Failure Paths
• Credential and API Migration Checks
• What the continueErrorOutput details Field Changes
• Automating the Gate: n8n in Your CI Pipeline
• India Context: Workflow Automation in the QA Market
• Key Takeaways
• FAQ

What n8n 2.35.3 Actually Changed

n8n 2.35.3 is a patch release on the 2.35.x line, published on August 14, 2026. It ships five bug fixes and one feature, and I am reading the official GitHub release notes as I write this. Two of those “bug fixes” are API surface changes, which is why I treat this release as more than a routine patch.

Here is the full change list for n8n 2.35.3:

• Google Ads Node migrated from the sunset v21 API to v25. This is the one that breaks things.
• Microsoft Teams Node restored the Group.ReadWrite.All OAuth2 scope.
• continueErrorOutput mode now allows a details field to pass through.
• Workflow publication outbox processing is now bounded with an abort deadline.
• Ready-to-run demo templates updated to a current OpenAI model.
• Feature: skip update approval for workflows created in the same Instance AI session.

Context matters here. If you are still on 2.35.2, you are already three patches behind: 2.35.4 landed on August 19, 2.35.5 on August 20, and 2.36.3 opened the next minor line the same day. n8n ships fast, which is exactly why you need a repeatable upgrade gate instead of gut feel.

Reading release notes like a QA engineer is different from reading them like a user. A user skims for “is anything faster or prettier.” I read for the three things that break workflows: API migrations, credential or permission changes, and behavior changes to error handling or data shapes. All three of those are present in this single patch, which is rare for a point release and why it deserves a closer look than the version number suggests.

Why a Patch Release Still Needs a QA Gate

The “patch means low risk” assumption is wrong, and it is the most expensive assumption in workflow automation. A patch release changes the same code paths your production workflows run on. The difference between a patch and a minor release is mostly intent, not blast radius.

Here is what I actually look at before deciding whether to gate an upgrade. n8n is not a small project. The n8n-io/n8n repository sits at 201,410 stars and 60,250 forks as of August 2026, written in TypeScript with 400+ integrations. The npm package saw 461,688 downloads in the last month alone. That is a lot of moving parts, and every one of them is a potential failure point when you upgrade.

Three of the six items in this release touch areas that break silently:

• An API migration (Google Ads v21 to v25) changes the endpoints and field shapes a node calls.
• An OAuth scope restore (Microsoft Teams) changes what permissions a credential actually has after re-authorization.
• An error-mode change (continueErrorOutput details) changes what data your failure branches receive.

None of these throw a loud, obvious error at startup. They degrade quietly. I have watched a Google Ads migration take down a month-end revenue report because nobody noticed the v21 API was sunset and the node had been quietly fixed in the release notes. The workflow still “ran.” It just pulled nothing.

The Upgrade Risk Assessment

Before I upgrade anything, I sort every change in the release into a risk tier. Here is how I score the six n8n 2.35.3 changes:

• HIGH — Google Ads v21 to v25. A breaking API migration. If you use the Google Ads node, verify it end to end before you deploy. A deprecated API version is a ticking clock, and the node now points somewhere else.
• MEDIUM — Microsoft Teams OAuth2 scope restore. A scope change means existing credentials may need a fresh consent flow. Test that your Teams notifications still send after upgrade.
• MEDIUM — continueErrorOutput details field. Behavior change in the error path. If your workflows branch on error output, the shape of that output just changed.
• LOW — publication outbox abort deadline. A reliability improvement. It should only make things better, but watch for any workflow that depended on long-running outbox processing.
• LOW — demo template OpenAI model update. No production impact unless someone copied a demo template into production (it happens).
• LOW — skip update approval for Instance AI session workflows. A governance change. If your team relies on update-approval as a review step, confirm this does not silently bypass it for AI-generated workflows.

That last one is worth a pause. The feature skips update approval for workflows created in the same Instance AI session. If you run n8n with AI-assisted workflow building enabled, the approval step you thought was catching bad changes may not fire for those workflows. That is a process question, not just a code question.

The 7-Step QA Upgrade Checklist

Here is the exact sequence I run before any n8n patch or minor release goes live. It takes under an hour once you have it scripted.

1. Inventory your nodes. Export every workflow and grep for the node types that appear in the release notes. For this release, that means n8n-nodes-base.googleAds and n8n-nodes-base.microsoftTeams.
2. Pin and snapshot. Record the current n8n version, export the workflow JSON, and snapshot the credential list before touching anything.
3. Read the release notes against your inventory. Match every API migration, scope change, and deprecation to the nodes you actually run. This is where most teams skip.
4. Stage on a non-production instance. Upgrade a staging instance first. Never upgrade production directly from a version three patches behind.
5. Run trigger and branch smoke tests. Fire each webhook, schedule, and manual trigger, then assert on the branch outcome. I show the TypeScript for this below.
6. Re-authorize credentials. For any node with an OAuth scope change, disconnect and reconnect the credential, then confirm the scope list.
7. Run failure-path tests with continueErrorOutput on. Force a node to fail and confirm the details field flows into your error handler the way you expect.

If any step fails, the release stays in staging. That is the whole gate.

Testing Triggers, Branches, and Failure Paths

The mechanics of n8n workflow testing are straightforward once you stop treating a workflow like a black box. I test three things: does the trigger fire, does the branch go the right way, and does the failure path do what it says. If you want the deeper version of this, I wrote a full walkthrough in n8n Workflow Testing: Test Triggers, Branches, and Failure Paths and a hands-on mini-project in n8n Workflow Testing: A Hands-On QA Mini-Project.

Here is a TypeScript example that fires an n8n webhook trigger and asserts on the result. This is the kind of smoke test you can run against a staging instance after upgrade.

// smoke-n8n-webhook.test.ts
import { expect, test } from '@playwright/test';

const WEBHOOK_URL = process.env.N8N_TEST_WEBHOOK_URL!;

test('webhook trigger returns 200 and expected branch payload', async ({ request }) => {
  const res = await request.post(WEBHOOK_URL, {
    data: { userId: 42, action: 'upgrade_verified' },
  });

  expect(res.status()).toBe(200);
  const body = await res.json();

  // The workflow branches on action; assert the branch landed where we expect
  expect(body.executionPath).toBe('success_branch');
  expect(body.details).toBeDefined(); // continueErrorOutput details field
});

For scheduled triggers, I do not wait for the cron to fire. I use the n8n REST API to trigger the workflow manually and poll the execution status:

# Manually trigger a workflow and poll its execution
curl -X POST "https://n8n-staging.example.com/api/v1/executions/123" \
  -H "X-N8N-API-KEY: $N8N_API_KEY"

The point is to exercise the same code path the production schedule hits, without waiting for the schedule.

Branch Coverage: Every If/Else Path

Triggers get the attention, but branches are where the silent bugs live. An n8n workflow is a graph, and every IF, switch, or filter node is a decision your test needs to exercise. I count the decision points in the workflow, then make sure I have a test input for each outgoing edge.

Here is a concrete pattern. Say a lead-routing workflow branches on the value of a lead.score field. I write one test per branch, not one test that happens to pass on the happy path:

// branch-coverage.test.ts
import { expect, test } from '@playwright/test';

const WEBHOOK_URL = process.env.N8N_TEST_WEBHOOK_URL!;

test('high-score lead routes to sales branch', async ({ request }) => {
  const res = await request.post(WEBHOOK_URL, { data: { lead: { score: 90 } } });
  const body = await res.json();
  expect(body.routedTo).toBe('sales');
});

test('low-score lead routes to nurture branch', async ({ request }) => {
  const res = await request.post(WEBHOOK_URL, { data: { lead: { score: 40 } } });
  const body = await res.json();
  expect(body.routedTo).toBe('nurture');
});

test('missing score routes to failure path', async ({ request }) => {
  const res = await request.post(WEBHOOK_URL, { data: { lead: {} } });
  const body = await res.json();
  expect(body.routedTo).toBe('error');
  expect(body.details).toBeDefined(); // continueErrorOutput details field
});

This is the same discipline you apply to API or UI tests, just pointed at a workflow graph. If you want to track which workflow version a test ran against, snapshot the version before upgrade and diff it after, which I cover in n8n Workflow Version Checks for QA Teams.

Credential and API Migration Checks

The Google Ads v21 to v25 migration in n8n 2.35.3 is the highest-risk item in the release, and here is why. A sunset API version does not fail immediately. Google deprecates it, then eventually turns it off. The n8n maintainers migrated the node in a patch release precisely because v21 was on its way out. If your workflow is still expecting v21 field shapes, the migration changes the payload it receives.

I verify two things for the Google Ads node:

• Field mapping. Confirm the fields your workflow reads (campaign ID, metrics, ad group) still exist under v25. Re-run a real report and diff the output against the pre-upgrade snapshot.
• OAuth token validity. After upgrade, disconnect and reconnect the Google Ads credential, then trigger a live pull. A stale token paired with a new API version fails in confusing ways.

The Microsoft Teams change is the same shape. The Group.ReadWrite.All OAuth2 scope was restored, which means a credential created while the scope was missing may not have it. Re-authorize and confirm the scope is present before trusting a Teams notification workflow to run unattended.

One more item hides in the “low risk” bucket. The ready-to-run demo templates were updated to a current OpenAI model, which means a template you pulled from the n8n template library a few months ago may now point at a different model and cost profile than what you originally tested. If any production workflow started life as a copied demo template, that is worth a quick audit after this upgrade. I flag it because I have seen more than one team quietly run a demo template in production because “it already worked.”

What the continueErrorOutput details Field Changes

This is the change most teams will not notice until it bites them, so I want to be specific. In n8n, a node can be configured to continue on error instead of stopping the workflow. When you enable that, the error output flows to the next node. Before n8n 2.35.3, that output did not carry a details field in every path. The fix in this release allows the details field through in continueErrorOutput mode.

Why QA cares: if you built an error-notification branch that reads the error message, the shape of the data that branch receives just changed. A branch that was parsing error.message may now also have error.details, which is richer but also different. If you were relying on the absence of details for any logic, that assumption is now broken.

My check is simple. Force a node to fail on staging, capture the continueErrorOutput payload, and confirm your error handler still parses it correctly. Richer error data is a win, but only if your handlers know it is coming.

Automating the Gate: n8n in Your CI Pipeline

Once the checklist is scripted, it belongs in CI, not in a wiki. A release gate that runs on a schedule only runs when someone remembers it. A gate in your pipeline runs on every change.

Here is a minimal GitHub Actions job that runs the webhook smoke test against a staging n8n instance before a deploy is allowed to proceed:

# .github/workflows/n8n-gate.yml
name: n8n-upgrade-gate
on:
  pull_request:
    branches: [main]

jobs:
  n8n-smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - name: Smoke test n8n webhook trigger
        env:
          N8N_TEST_WEBHOOK_URL: ${{ secrets.N8N_TEST_WEBHOOK_URL }}
        run: npx playwright test smoke-n8n-webhook.test.ts

The same release-gate discipline I apply to n8n workflows is the discipline I apply to test automation itself. If you want the full template for gating an AI or automation pipeline in CI, I published one in PromptFoo DeepEval CI Gate: QA Template. The principle is identical: nothing ships without a passing check.

Two things make the gate actually stick. First, a gate only works if “failing” blocks the deploy, not just turns a checkmark red. Wire the job into your branch protection rules so a red run stops the merge. Second, record which n8n version the test ran against. A smoke test that passes against 2.35.2 tells you nothing about 2.35.3 unless the version is pinned in the test output. I tag every run with the version, so a month from now I can answer “did this pass before or after the Google Ads migration” without guessing.

India Context: Workflow Automation in the QA Market

Workflow automation is quietly becoming a line item in Indian QA and SDET job descriptions. Companies that run n8n, Zapier, or Make for internal ops need someone who can both build the automation and prove it does not break. That is a testing skill, not just an automation skill.

What I am seeing in the last few quarters: product companies and funded startups in Bengaluru, Pune, and Hyderabad list “workflow automation” and “n8n” alongside Playwright and CI/CD in SDET postings. The reason is simple. When a marketing-to-CRM sync or a lead-routing workflow breaks, it does not fail a test suite. It costs revenue, and nobody notices until a report is empty. The engineer who can gate that workflow before it breaks is worth more than the one who only writes UI tests.

There is a second reason this matters for Indian QA engineers specifically. The tools are free and self-hostable, so the barrier to entry is near zero. n8n runs on a ₹500-a-month VPS or your laptop with Docker. You can build a release-gate pipeline for a workflow automation stack without asking your company for budget, which makes it one of the cheapest ways to move from “I write test cases” to “I own release quality.” That is a career-shaping distinction, not a résumé keyword.

I am not going to quote a salary figure I cannot verify, but the direction is consistent with what I published in SDET Salary in India 2026: breadth in automation plus a release-governance mindset is what separates the mid-career engineer from the senior one. n8n release testing is a concrete, demonstrable version of that mindset.

Key Takeaways

• n8n 2.35.3 (August 14, 2026) ships five bug fixes and one feature, and two of those “bug fixes” are API surface changes you must test.
• The Google Ads v21 to v25 migration is the highest-risk item in this release; verify it end to end before deploy.
• The Microsoft Teams OAuth2 scope restore means existing credentials may need re-authorization.
• The continueErrorOutput details field changes the shape of error-path data; re-test your failure handlers.
• A patch release is not low risk by default. Run a seven-step upgrade gate and put it in CI.

FAQ

Do I need to test n8n 2.35.3 if I do not use Google Ads or Microsoft Teams?

Mostly you can move faster. The continueErrorOutput details change still touches every workflow that uses continue-on-error, so run at least a failure-path smoke test on staging. If you use neither Google Ads nor Microsoft Teams nor continueErrorOutput, this patch is genuinely low risk for you.

How do I find which nodes my workflows actually use?

Export your workflows as JSON and grep the type field for the node names. Alternatively, n8n exposes them through the REST API. Match that list against the release notes and you have a targeted risk assessment instead of a guess.

What is the fastest way to smoke test a webhook trigger after upgrade?

Fire the webhook URL from a script (curl, Postman, or a Playwright test) and assert on the HTTP status and the response payload. I show the TypeScript version in the section above. A manual trigger through the n8n REST API covers scheduled workflows without waiting for the cron.

Should I skip versions when upgrading n8n?

Avoid jumping many versions at once when you can. Each release in between can carry its own API migrations and scope changes. If you are several patches behind, stage the jump and read the combined release notes as one change set before running the checklist.

Where can I learn n8n workflow testing in more depth?

I have a full guide at n8n Workflow Testing: Test Triggers, Branches, and Failure Paths and a hands-on project at n8n Workflow Testing: A Hands-On QA Mini-Project. Start there if you want the step-by-step version.

How often should I upgrade n8n?

Follow a rhythm instead of upgrading on impulse. I hold production on a version for a few weeks, watch the patch releases land, then batch the upgrade once the line stabilizes. For the 2.35.x line, that means waiting until the rapid-fire patches (2.35.3, 2.35.4, 2.35.5) settle before staging a single jump and running the checklist once, rather than testing every point release in between.