Documentation link
No response
Issue type
Missing documentation
Problem
Problem to solve
We are reviewing the official CLI for controlled migration automation that must stop after a database connection failure, without reconnecting or reapplying work after an ambiguous outcome.
This is a source-level review, not a reproduced failure report.
Observations from official source
In CLI 2.119.0:
- The PostgreSQL layer permits connection fallback and documents pool reconnection after an idle connection is lost.
- Migration files containing explicit transaction-control statements take the sequential execution path.
- That path executes the file’s statements before inserting its version, name and statements into
supabase_migrations.schema_migrations.
The inspected legacy implementation in 2.116.0 also records history after the file’s statements.
For a file containing its own BEGIN and COMMIT, this appears to place the history insert after the file’s transaction has committed.
We have not demonstrated automatic replay of a failed SQL statement or migration. We have also not reproduced a connection-loss scenario with the shipped executable.
Suggested improvement
Guidance requested
- Is there an officially supported mechanism to stop the command after a PostgreSQL connection is lost, without pool reconnection or connection fallback? We distinguish this from TCP packet retransmission and from separate, explicitly initiated CLI commands.
- For an unchanged migration file containing its own
BEGIN and COMMIT, can the CLI atomically commit the migration and its history entry? If not, what consistency guarantees and limitations apply?
- If the connection is lost during
COMMIT or before the history insert is acknowledged, what read-only observations are recommended to classify the outcome without automatic repair or reapplication?
The automation must preserve the original migration bytes and version. We are seeking guidance before proposing an implementation or running further qualification.
Additional context
Source references
No credentials, project identifiers, private repository references, customer data or raw execution logs are included.
Documentation link
No response
Issue type
Missing documentation
Problem
Problem to solve
We are reviewing the official CLI for controlled migration automation that must stop after a database connection failure, without reconnecting or reapplying work after an ambiguous outcome.
This is a source-level review, not a reproduced failure report.
Observations from official source
In CLI 2.119.0:
supabase_migrations.schema_migrations.The inspected legacy implementation in 2.116.0 also records history after the file’s statements.
For a file containing its own
BEGINandCOMMIT, this appears to place the history insert after the file’s transaction has committed.We have not demonstrated automatic replay of a failed SQL statement or migration. We have also not reproduced a connection-loss scenario with the shipped executable.
Suggested improvement
Guidance requested
BEGINandCOMMIT, can the CLI atomically commit the migration and its history entry? If not, what consistency guarantees and limitations apply?COMMITor before the history insert is acknowledged, what read-only observations are recommended to classify the outcome without automatic repair or reapplication?The automation must preserve the original migration bytes and version. We are seeking guidance before proposing an implementation or running further qualification.
Additional context
Source references
No credentials, project identifiers, private repository references, customer data or raw execution logs are included.