All rules Rule SR017 · TX
SurrealDB · beta
critical
TX · Transactions
free in the CLI, --engine=surrealdb

Can SurrealDB nest transactions?

Nested BEGIN

Critical: SurrealDB refuses the migration, loses data, or leaks a credential.

What happens

Observed on SurrealDB 3.0.2: BEGIN; BEGIN; ... COMMIT; COMMIT; fails the whole query with "Tried to start a transaction while another transaction was open".

Why it is dangerous on a populated table

Table size does not change this one: SurrealDB rejects the whole query before it applies anything, on an empty database and a full one alike.

Fires on

BEGIN;
BEGIN;
DEFINE FIELD nickname ON TABLE user TYPE option<string>;
COMMIT;
COMMIT;

The safe pattern

Use one transaction per file. If the migration tool already wraps each file in a transaction, drop the file's own BEGIN and COMMIT.

BEGIN;
DEFINE FIELD nickname ON TABLE user TYPE option<string>;
COMMIT;

Fixtures

The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.

Fires (1)

nested
BEGIN;
BEGIN;
DEFINE FIELD nickname ON TABLE user TYPE option<string>;
COMMIT;
COMMIT;

Stays silent (2)

sequential
BEGIN;
DEFINE FIELD nickname ON TABLE user TYPE option<string>;
COMMIT;
BEGIN;
DEFINE FIELD bio ON TABLE user TYPE option<string>;
COMMIT;
single
BEGIN;
DEFINE FIELD nickname ON TABLE user TYPE option<string>;
COMMIT;

How to check locally

Catch this before it ships

SurrealDB support is in beta: this rule runs locally in the free CLI over .surql migrations, static only, and not in the hosted service yet. No install, nothing leaves your machine:

npx bolvrk check migration.surql --engine=surrealdb