n8n-io/n8n · error · Error

Pre-seeding created ${String(dataTableIds.length)} data tabl

Error message

Pre-seeding created ${String(dataTableIds.length)} data table(s) but the case declares ${String(scenarioSeedTables.length)}; cannot map names to ids.

What it means

Thrown in the scenario data-table pre-seed block when client.restoreThread returns a number of created data-table ids that does not equal the number of schemas the harness sent. restoreThread is contractually expected to return ids in input order so the harness can map each DECLARED table name to its created id; a length mismatch makes that mapping unsafe, so the harness fails rather than mis-seed scenario rows against the wrong table.

Source

Thrown at packages/@n8n/instance-ai/evaluations/harness/build-workflow.ts:527

					client,
					scenarioSeedTables,
					config.preRunDataTableIds,
					logger,
					config.laneTag,
				);
				// `uniquifyNames: false` stays — the harness mints the suffix so it knows
				// which name to give the agent below.
				const schemasOnly = uniquifyScenarioTableNames(scenarioSeedTables).map((table) => ({
					...table,
					rows: undefined,
				}));
				const { dataTableIds } = await client.restoreThread(threadId, [], [], schemasOnly, [], {
					uniquifyNames: false,
				});
				// restoreThread returns ids in input order; a length mismatch means we
				// can't safely map names to ids, so fail rather than mis-seed.
				if (dataTableIds.length !== scenarioSeedTables.length) {
					throw new Error(
						`Pre-seeding created ${String(dataTableIds.length)} data table(s) but the case declares ${String(scenarioSeedTables.length)}; cannot map names to ids.`,
					);
				}
				// Keyed by the DECLARED name — what a scenario writes.
				scenarioSeedTables.forEach((table, index) => {
					scenarioTableIdsByName[table.name] = dataTableIds[index];
				});
				restoredDataTableIds = [...restoredDataTableIds, ...dataTableIds];
				// The agent looks up the name that exists, not the declared one.
				scenarioSeedTablesNote = buildSeededTablesNote(schemasOnly);
				logger.info(
					`  Pre-seeded ${String(dataTableIds.length)} scenario data table schema(s)${config.laneTag ?? ''}`,
				);
			}
		} catch (error: unknown) {
			seedingFailed = true;
			throw error;
		}

View on GitHub (pinned to 5ac6606e81)

Solutions

Ensure the case's execution-scenario tables have distinct names (the harness uniquifies, but confirm the input).
Update the instance-ai backend so restoreThread returns one id per input schema and surfaces per-table errors instead of dropping them.
If using an older backend, upgrade to a version that honors the input-order id contract for data tables.

Defensive patterns

Strategy: validation

Validate before calling

// Before restoring, assert distinct declared table names so the backend cannot dedupe them.
const names = scenarioSeedTables.map((t) => t.name);
const dup = names.find((n, i) => names.indexOf(n) !== i);
if (dup) throw new Error(`Duplicate scenario table name "${dup}"; restoreThread would dedupe and the id map breaks.`);

Prevention

Ensure scenario table names are unique in the fixture (the harness uniquifies, but verify inputs).
Pin the instance-ai backend version that returns one id per schema in input order.
If restoreThread can ever partially fail, make it throw rather than return a short id array.

When it happens

Trigger: The backend created fewer/more tables than requested (e.g. deduplicated names server-side, a schema rejected, a partial failure swallowed by restoreThread), so the returned id array length diverges from scenarioSeedTables.length.

Common situations: Backend version that dedupes or rejects some table schemas; a case declares duplicate table names after uniquifyScenarioTableNames; restoreThread silently dropped a creation error.

Related errors

AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12). Data as JSON: /api/errors/9d06ca22186f69b7. Report an issue: GitHub.