n8n 2.33.4 Baserow Workflows Fail to Activate: Fix 'Could not resolve parameter dependencies'

n8n 2.33.4 Baserow Workflows Fail to Activate: Fix “Could not resolve parameter dependencies”

If an n8n workflow stopped activating immediately after an upgrade to 2.33.4, contains a Baserow node, and logs the error below, do not start by deleting the node, rebuilding the workflow, or rotating credentials:

Could not resolve parameter dependencies. Max iterations reached!
Hint: If `displayOptions` are specified in any child parameter of a parent
`collection` or `fixedCollection`, remove the `displayOptions` from the child parameter.

As of August 7, 2026, n8n’s repository contains at least two independent reports. Issue #35783 says Baserow workflows stopped activating after an upgrade from 2.32.7 to 2.33.4 and recovered after rollback to 2.32.7. n8n moved that report into internal ticket GHC-9218. Issue #35787 reports the same dependency error together with workflows that could not be activated and a webhook returning Published version not found.

I installed the exact internal package versions declared by n8n 2.32.7 and 2.33.4 into isolated directories and passed Baserow’s nested filter schema to the real getNodeParameters() resolver. No database, credential, Baserow API, or model call was involved. The old dependency set passes; the new set deterministically throws the same Max iterations reached error. Changing one dependency key on the newly added timezone field makes the same resolver call pass.

The safest short-term response is to preserve data, validate rollback to a known-good n8n version, and wait for an upstream fix. The local schema edit described below is root-cause evidence, not a production patch.

Verify that your failure matches this regression

The strongest match is: the workflow worked before 2.33.4, contains Baserow, fails while n8n builds the workflow dependency index or activates the workflow, and workflows without Baserow still work. Issue #35783 reports exactly that control pattern.

Do not assume every Max iterations reached message is this bug. Parameter dependency resolution is shared infrastructure, so other invalid nested schemas can produce a similar symptom. Version, node type, and before/after-upgrade evidence still matter.

Deterministic 2.32.7 vs 2.33.4 reproduction

The npm package mappings are:

n8n	n8n-workflow	n8n-nodes-base	Result
2.32.7	2.32.1	2.32.4	Pass
2.33.4	2.33.1	2.33.1	Exact Max iterations error
2.33.5 stable	2.33.1	2.33.1	Same core package set; same deterministic repro applies
2.34.2 pre-release	2.34.1	2.34.1	Exact Max iterations error still reproduced
2.33.x packages + diagnostic dependency change	2.33.1	2.33.1	Pass

The local reproduction asset is structured as:

You can inspect the public GitHub repro asset or download the runnable fixture directly: n8n Baserow parameter dependencies repro ZIP.

experiments/n8n-baserow-parameter-dependencies-repro/
├── README.md
├── repro.cjs
├── repro/
├── fixed/
├── logs/
├── version-matrix.md
├── v232/
├── v233/
└── v234/

Run the same fixture against both dependency sets and then against the diagnostic schema change:

node repro.cjs v232
node repro.cjs v233
node repro.cjs v233 --patch-display-options
node repro.cjs v234

The 2.32.7 dependency set exposes these nested Baserow filter fields:

field
operator
value

That case resolves successfully. The 2.33.4 dependency set adds one field:

field
operator
timezone
value

Without starting n8n Server or connecting a Baserow account, the real resolver now produces the same error reported upstream:

RESULT: ERROR: Could not resolve parameter dependencies. Max iterations reached!
Hint: If `displayOptions` are specified in any child parameter of a parent
`collection` or `fixedCollection`, remove the `displayOptions` from the child parameter.

This narrows the failure from a deployment-specific symptom to a deterministic interaction between the Baserow parameter definition and n8n’s parameter resolver.

The triggering schema difference

In [email protected], the new timezone field is controlled by:

displayOptions: {
  show: {
    '../operator': [
      'date_is',
      'date_is_not',
      'date_is_before',
      'date_is_after',
      'date_is_within',
      // ...
    ],
  },
}

In the nested field list used by the resolver, operator and timezone are siblings. With ../operator, the dependency calculation does not converge. For diagnosis only, I cloned the schema in memory and changed only the dependency key:

timezone.displayOptions = {
  show: {
    operator: timezone.displayOptions.show['../operator'],
  },
};

The exact same resolver call then succeeds:

RESULT: OK
{
  "field": "1",
  "operator": "date_is",
  "timezone": "UTC",
  "value": "2026-08-07"
}

That proves the dependency path is sufficient to trigger the isolated regression. It does not prove that editing node_modules is a safe production fix; the diagnostic change has not been approved upstream or validated against n8n’s complete regression suite.

Production recovery

If this has stopped production automation, recover service before experimenting with installed package files:

1. Back up the database, encryption key, configuration, and exportable workflows.
2. Preserve the exact version, Baserow node information, first error, upgrade time, and last successful run.
3. Validate rollback to your known-good version in a controlled environment. The public report confirms 2.32.7 restored its affected workflows.
4. After rollback, verify activation, webhook/trigger registration, and a no-side-effect Baserow execution.
5. Pin the recovered version until an upstream release passes the same regression test.

n8n Cloud users generally cannot select the server version. Preserve workflow IDs, timestamps, node details, and logs for n8n support instead of recreating workflows that only appear missing.

“Published version not found” does not prove deletion

Issue #35787 includes a Baserow webhook response in this shape:

{
  "code": 404,
  "message": "Published version not found for workflow with id ..."
}

That 404 proves a usable published version was unavailable at that moment. It does not prove the underlying workflow entity was deleted. Activation state, published versions, editor visibility, and the stored workflow are separate layers.

Before importing over an existing ID or rebuilding a workflow, verify through backups, exports, the database/API where available, or n8n support.

Why workflows that do not use date filters may still fail

The isolated trigger is the new date-filter timezone field, but the upstream reports describe broader activation failures. That is plausible because the exception appears while n8n builds the workflow dependency index and evaluates the node parameter schema, before a Baserow API request executes. A workflow can therefore fail activation even when its current operation does not actively use the date filter.

I did not run a complete n8n Server operation matrix, so this is a scoped explanation rather than a claim that every Baserow operation is affected. To establish your own blast radius, keep the workflow fixed and compare activation with the Baserow node present versus removed.

Upstream status

As of August 7, 2026, n8n GitHub Releases lists 2.33.5 as stable and 2.34.2 as a pre-release. Their published release notes do not list this Baserow regression as fixed. More importantly, 2.33.5 still declares the same [email protected] + [email protected] pair as 2.33.4, and I installed the 2.34.2 2.34.1 + 2.34.1 package set and reproduced the exact same resolver error. Issue #35783 is tracked internally as GHC-9218, but neither tracking nor a newer release number proves the fix shipped.

The evidence currently supports:

2.32.7: public rollback report restored affected workflows; local resolver passes
2.33.4: public activation failures; local resolver reproduces the exact error
2.33.5 stable: same 2.33.1 core package pair as 2.33.4; same deterministic repro applies
2.34.2 pre-release: installed 2.34.1 core package pair still reproduces the exact error
official fixed version: not verified as of 2026-08-07

Test boundaries

The local test ran on macOS with Node.js 22.18.0. Docker CLI existed but the daemon was not running, so I did not execute a full n8n Server, Cloudron, n8n Cloud, database, or live Baserow activation matrix. The result is narrower: the Baserow schema shipped in the dependency sets declared by n8n 2.33.x and 2.34.2 deterministically triggers the real resolver while the 2.32.7 set does not.

If your workflow activates but an AI Agent skips its Tool, use n8n AI Agent Not Calling Tools. For generic workflow timeout, retry, and error handling, see n8n AI Workflow Error Handling. For Docker, Postgres, backups, and version pinning, see the Self-hosted n8n production baseline.

Recovery checklist

• Confirm before/after n8n versions.
• Confirm Baserow is present.
• Preserve the full dependency error.
• Back up database, encryption key, configuration, and workflows.
• Do not delete or overwrite workflows that only appear missing.
• Validate rollback to the known-good version.
• Recheck activation and a safe Baserow execution.
• Pin the recovered version until an upstream fix is verified.
• Rerun both the minimal resolver fixture and a full activation test after the upstream release.

Topic path / AI workflows

Continue through the production automation path

The workflow hub connects self-hosting, queue mode, webhooks, retries, observability and n8n implementation cases into one production-oriented learning path.

Open workflow hub → Review webhook hardening Subscribe for updates