[THEtheChad]

Fixes #459.

Since 0.12.0 (DuckDB 2.0), catalog and binder errors abort an open transaction by default. With autocommit=False, later statements fail, and commit() silently discards earlier writes. This affects snowflake-sqlalchemy's Table.create(checkfirst=True), which probes for a missing table using DESC TABLE. Snowflake instead rolls back only the failed statement and allows successful statements in the transaction to be committed.

FakeSnow now sets default_transaction_invalidation_policy = SYNTACTIC_ERRORS_DO_NOT_INVALIDATE, restoring DuckDB 1.x behavior for parser, binder and catalog errors. The setting is supported by the pinned DuckDB 2.0.0 and applies to both in-process connections and server sessions.

Runtime failures such as conversion and constraint errors still abort the whole transaction in DuckDB, which has no savepoints. To prevent a subsequent commit from silently discarding writes, the connection checks for an aborted transaction before conn.commit(), SQL COMMIT, implicit commits before supported DDL, and autocommit changes. It raises ProgrammingError with errno 9999 and SQLSTATE 99999, the project's existing convention for unsupported behavior. The error explains the difference from Snowflake and requires rollback before starting another transaction.

The guard leaves the transaction aborted until explicit rollback or connection close. This matters because the real Snowflake Python connector's autocommit() suppresses connector errors: server-mode conn.autocommit(...) can swallow the warning, but a subsequent conn.commit() still fails. SQL ALTER SESSION SET AUTOCOMMIT reports the error directly. Context-manager exit closes the connection even if its commit fails.

The check uses SELECT 1; DuckDB's Python API exposes no transaction-validity flag. In DuckDB 2.0.0 this query raises TransactionException in an aborted transaction and leaves no transaction open when run outside one. Ordinary rollback remains unguarded so callers can recover.

Remaining deviation: Snowflake preserves earlier writes after runtime failures; fakesnow rejects the commit instead. Statements attempted before rollback still encounter DuckDB's aborted-transaction error. Replaying earlier statements to emulate rollback of only one statement is outside this fix, especially because replay is unsafe for non-deterministic statements.

Validation: the five original regression cases fail on base 3f65f02. Expanded tests cover SQLAlchemy's check-first pattern, direct and server commits, implicit DDL commits, autocommit changes, rollback recovery, context-manager cleanup, and closed-connection error conversion. The full suite passes: 551 passed, 2 xfailed. Ruff lint and formatting pass; pyright reports 0 errors and 0 warnings.

Checked against a live Snowflake account (10.38): with autocommit off, after insert (1), a failing select * from no_such_table, and insert (2), the commit succeeds there and here and keeps both rows. After a runtime failure instead (insert into txn values ('x') into an INT column, 100038 (22018) there), Snowflake still commits both rows, while fakesnow refuses the commit: the deviation described above, now confirmed.

🤖 Generated with Claude Code

[THEtheChad]

Merge order: this overlaps #472 in fakesnow/cursor.py. Please merge this one first; I'll rebase #472 onto it, and adapt #472's tests to this PR's refusal of statements in an aborted transaction. #472's comment has the details.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

Live Snowflake: INSERT ... VALUES ('x') fails with 100038 (22018): Numeric value 'x' is not recognized, but conn.commit(), SQL COMMIT, and ALTER SESSION SET AUTOCOMMIT = TRUE all succeed; the earlier insert remains. This does not produce the expected transaction was aborted error or fakesnow (9999, "99999") code.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

On Snowflake, conn.autocommit(True) succeeds after the failed insert, and the following conn.commit() succeeds too. The earlier row remains; the expected transaction was aborted error is not raised.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

On Snowflake the failed integer conversion raises 100038 (22018): Numeric value 'x' is not recognized, but conn.commit() succeeds and commits the earlier insert. A subsequent rollback does not undo that commit, so the row count is 1 rather than 0.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

Live Snowflake allows SQL COMMIT and both ALTER SESSION SET AUTOCOMMIT variants after this failed insert; the aborted-transaction error is not raised. A temporary-table DDL follow-up also succeeded and preserved the earlier row. The persistent CREATE TABLE next_table probe could not be run with this account: 003540 (42501): SQL execution error: Creating table on shared database 'SNOWFLAKE' is not allowed.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

Both conn.autocommit(False) and conn.autocommit(True) return without an error on Snowflake after the runtime failure. The earlier row remains after rollback, rather than producing the expected exception and a zero count.

[tekumara]

Note

🤖 gpt-6-luna responding on behalf of tekumara

N/A to real Snowflake: this test requires context exit to raise because an earlier runtime failure aborted the transaction. Snowflake rolls back only the failed statement, so context exit can commit the earlier insert instead; this failed-commit path is fakesnow-specific.