Go conserva el fallo de orden de versiones corregido en TypeScript por #6038

[acacerescr]

Affected area

Migrations — paquete Go github.com/supabase/cli/pkg/migration y confirmación de la ruta utilizada por Hosted Branching.

Supabase CLI version

Inspección de código en v2.117.0 y en develop, commit 75b9e8156d4653f8f4ba04f3441c10ee38d51ef0. No se ejecutó db push ni SQL remoto para este reporte.

Operating system

macOS; el caso mínimo depende únicamente del orden de strings, no del sistema operativo.

Installation method

Checkout del repositorio oficial para inspección estática.

Problema

El issue #6036 se cerró mediante #6038. Ese PR corrigió la ruta TypeScript y declara explícitamente que no modifica Go. La función FindPendingMigrations de apps/cli-go/pkg/migration/apply.go conserva el merge de dos listas con órdenes incompatibles:

• ListLocalMigrations devuelve paths ordenados por nombre completo mediante fs.ReadDir.
• ListRemoteMigrations devuelve versiones ordenadas mediante ORDER BY version.
• FindPendingMigrations compara las versiones extraídas sin reordenar los paths locales.

No reporto una regresión del fix TypeScript: solicito triage de la implementación Go todavía presente y confirmación de si sigue siendo consumida por Hosted Branching u otros servicios.

Reproducción mínima sin base de datos

La siguiente invocación usa únicamente entradas sintéticas y llama a la función pura de Go:

local := []string{
    "201_legacy.sql",
    "20260101000000_new.sql",
    "202_legacy.sql",
    "203_legacy.sql",
}
remote := []string{"201", "202", "20260101000000", "203"}
pending, err := migration.FindPendingMigrations(local, remote)
fmt.Printf("pending=%v err=%v\n", pending, err)

Los paths están en el orden que devuelve fs.ReadDir; todas las versiones remotas tienen un archivo local. Por inspección del código, el resultado es:

pending=[202] err=Remote migration versions not found in local migrations directory.

El cursor remoto consume 202 al compararlo con 20260101000000; cuando alcanza 202_legacy.sql ya perdió la coincidencia. Este fragmento se ofrece como reproducción para el mantenedor: no afirmo haber compilado ni ejecutado el paquete Go en este checkout.

Expected behavior

Si todas las versiones están presentes en ambos lados, el comparador debe devolver cero pendientes y ningún error. Debe seguir rechazando versiones realmente ausentes y migraciones genuinamente fuera de orden; no debería sugerir modificar el historial para compensar una falsa ausencia.

Alcance que necesita decisión del mantenedor

1. ¿El paquete Go continúa consumido por Hosted Branching? ¿Qué implementación y versión usa la reconciliación administrada actualmente? Un fix del cliente TypeScript no prueba que haya cambiado ese servicio.
2. Si Go sigue soportado, ¿aceptarían portar la corrección de fix(cli): order migrations by version #6038 y sus regresiones? También habría que revisar consumidores que calculen offsets para --include-all, sin cambiar globalmente el orden usado para hashes o caches.
3. Para un historial secuencial corto seguido de timestamps, ordenar lexicográficamente por versión elimina la falsa ausencia pero no garantiza el orden de dependencias: con remote = ["201", "202", "203"], el timestamp cae antes de 203 y pasa a ser ErrMissingRemote; desde vacío, quedaría entre 202 y 203. ¿Existe una ruta soportada para esa transición sin renumerar historial ni relajar las comprobaciones? No propongo cambiar silenciosamente la semántica global a orden numérico.

Puedo preparar un parche y regresiones una vez que el alcance esté aceptado y el issue tenga open-for-contribution, conforme a CONTRIBUTING.md. No se ha iniciado un parche ni abierto un PR.

Referencias

• Fix previo TypeScript #6038
• Comparador Go, SHA inspeccionado
• Listado local Go
• Orden del historial remoto

No se adjuntan datos de proyectos, credenciales, logs privados ni SQL de aplicaciones. Todos los nombres y versiones del ejemplo son sintéticos.