Concurrent Executions Apply Schema Version Twice

[casba]

Hi,

We unintentionally ran the schemachange command in two separate Jenkins pipelines concurrently, and were surprised to see that each pipeline successfully applied the latest version of our schema. This generated two rows in the change_history table with duplicate contents, save for the timestamp. Is there any way to protect against concurrent execution using this tool? Looking closer at snowflakes supported SQL commands, it's not clear to me that it would be possible.

[CermitDFrog]

Reads don't block in Snowflake and schemachange reads the current change state early in the execution chain. This is the exact behavior I would expect.

[sfc-gh-tmathew]

Hello @casba

Thank you for reaching out. As @CermitDFrog pointed out, Schemachange is behaving as designed.

I cannot think of a way to block a client connection from executing a SQL statement because another connection is connected and executing a SQL statement on the same target database.

Closing the issue because we will not be able to fix it.