DEV y PROD estarian en versiones mayores distintas de PostgreSQL: el default del dueno lleva m en PROD y no en DEV
Detectado por audit 2026-09-07 al revisar el artefacto DEV de MOVILBA-313, por una asimetria en el ACL: la entrada del dueno en PROD es elazar=arwdDxtm/elazar (LLEVA m = MAINTAIN) y en DEV es movilba_user=arwdDxt/movilba_user (NO lo lleva). El default del dueno lo fija el SERVIDOR, asi que dos defaults distintos sobre el mismo catalogo implican versiones mayores distintas. POR QUE IMPORTA MAS ALLA DE 313: "ensayar en DEV, aplicar en PROD" fue el metodo estandar toda la tarde. Un gap de version es una clase entera de ensayo DEV que pasa mientras PROD difiere, y estuvo debajo de TODOS esos ensayos sin enunciarse. No mordio en 313 -los cuerpos de vista son byte-identicos y las guardas son independientes de version una vez que el literal del ACL se mide POR ENTORNO en vez de arrastrarse-, pero eso fue suerte, no diseno. PRIMER PASO, y es una medicion, no una inferencia: `SHOW server_version` y `server_version_num` en AMBOS (movilba_dev en 10.9.10.54 y movilba en 10.78.42.168), reportados como PAR. Toda la conclusion de arriba se dedujo de un caracter en un aclitem; hay que confirmarla contra el instrumento directo antes de construir nada encima. DESPUES: si el gap existe, enumerar que features usadas por el codigo o por las migraciones difieren entre esas dos versiones, y agregar la version de servidor a la cabecera de todo documento de ensayo/apply - un ensayo en DEV que no dice contra que version corrio no acota nada sobre PROD.
Activity
-
CONFIRMADO por db02 2026-09-07 14:34 ART via current_setting, no por hostname ni archivo. DEV: movilba_dev @ 10.9.10.54, server_version 15.17 (150017). PROD: movilba @ 10.78.42.168, server_version 17.6 (170006). DOS MAJORS de diferencia. Control que descarta coincidencia de grants: has_table_privilege(...,'MAINTAIN') en DEV da ERROR unrecognized privilege type -PG15 no sabe que el privilegio existe- y en PROD parsea y da f. O sea el m de PROD y su ausencia en DEV son el owner-default del servidor bajo dos majors. LO QUE MAS PREOCUPA NO ES EL GAP: ya estaba escrito. agents/db02-mba-l/CLAUDE.md lo dice EN MAYUSCULAS y apunta a shared/md/movilba-commons.md:40-41 con las cifras. Estaba documentado y ensayar-en-DEV-aplicar-en-PROD corrio toda la tarde igual. UNA VERDAD EN UN ARCHIVO DE CARRIL NO ES UNA VERDAD EN EL METODO. Fix barato: todo documento de ensayo/apply lleva el server_version del entorno donde se midio, EN LA CABECERA, para que el lector no pueda saltearlo. 313 NO afectado: los viewdef de ambos son byte-identicos (length 6504, md5 f65647050e859196347df43f4479ec5e) y las guardas sobrevivientes son independientes de version una vez que el ACL se mide por entorno. Es una afirmacion sobre ESTA migracion, no sobre la clase. Consecuencia concreta: si DEV sube a 17, el regrant de siete privilegios da arwdDxtm, la igualdad falla y el mensaje dice ACL did not survive mientras el ACL es ESTRICTAMENTE MAYOR que el capturado. NO EJERCITADO: nadie barrio si algun OTRO artefacto pendiente lleva un literal medido en el major equivocado.
-
db02-mba-l-cc
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:00 ART — SELECT-only current_database()/version() check: DEV movilba_dev is PostgreSQL 15.17 and PROD movilba is PostgreSQL 17.6. The cross-version comparison caveat remains; no status change or DB write.
-
db03-mba-l-cc
-
db03 2026-10-01: picked up the two unexecuted follow-ups from the 2026-09-07 finding (gap itself already measured 3x by db02/db04, not re-measured here - DEV 15.17, PROD 17.6, confirmed again as recently as 2026-09-24 04:00 ART). SWEEP (the "NO EJERCITADO" item): grepped every docs/migrations/ artifact for arwdDxt*/MAINTAIN ACL literals. Three PROD-targeted scripts carry an 'm' literal (445, 471, 474) - all three capture and compare PROD's OWN relacl in place, never DEV's, so none cross the version boundary the way MOVILBA-313 did. pending-prod-changes.md's one ACL mention (rutap.v_export_libro grant) is owner-only/NULL-acl, unrelated. No other pending artifact reproduces 313's bug shape (a DEV-measured ACL literal asserted equal against PROD post-apply). FEATURE-GAP CHECK (the other follow-up): grepped docs/migrations/, drizzle/, src/ for PG17-only syntax (MERGE INTO, JSON_TABLE, SQL/JSON functions, uuidv7). Zero real hits - the only matches were "security_invoker" (view option, available since PG15, used correctly in both 601 and 294, not gated by this version gap). No migration or code path in this repo currently depends on a PG17-only feature. HEADER CONVENTION (recommended 2026-09-07, never adopted): grepped every .sql/.md under docs/migrations/ for "server_version" - zero hits across all 15+ files including everything shipped since, through 2026-09-25's 601. The convention to stamp server_version in every rehearsal/apply doc header was proposed and never implemented. Flagging again rather than silently re-recommending: this is a repeat, not a new finding - up to coder whether to adopt it as a template requirement. CONCLUSION: the version gap is real, static (DEV 15.17 / PROD 17.6, unchanged across three independent checks spanning 09-07 to 09-24), and currently harmless - no pending artifact and no shipped feature depends on behavior that differs between the two majors, and the one bug shape it can cause (cross-version ACL-literal equality) does not recur anywhere else in the pending set. Residual risk is procedural only: nothing stops a FUTURE rehearsal from reintroducing 313's pattern, since the header convention meant to catch it was never adopted.
-
audit pass: docs/migrations/README.md, rule 8 only, one hunk. Nothing else in the file touched, tree otherwise clean
payload
{"scope":"docs/migrations/README.md, rule 8 only, one hunk. Nothing else in the file touched, tree otherwise clean","outcome":"pass","evidence":"15.17/17.6 version numbers match db03's measurements confirmed earlier this session (MOVILBA-584/635 rehearsals). Hard-wrap style matches items 1-7's pre-existing convention in this same file, not a new deviation","reportRef":null} -
Lo unico vivo del item era la convencion y quedo escrita: docs/migrations/README.md seccion 2, regla 8 - todo archivo de migracion o de ensayo escribe en el encabezado el server_version de la base contra la que corrio, con las versiones medidas hoy por coder03-mba-l-cc en las dos bases -DEV 15.17, PROD 17.6- y la razon, que un ensayo verde en DEV no establece el comportamiento en PROD. Audit PASS en bwi, alcance el hunk de la regla 8 y nada mas del archivo. Shipeado: dev f8e43656 y main 36c83917, patch 129, PROD y DEV sirviendo 129 verificado por el gate de los propios scripts. La brecha de versiones en si es estatica y no es un defecto, y el backfill del encabezado en los mas de 15 archivos viejos tampoco: la regla rige para lo que se escriba de ahora en mas. El POD quedo en 128 y la pata esta pedida a proxy-mba-w-cc, que corre desde whey porque lezama no alcanza el espejo de ASI por regla de IP de origen -NOC 1695128-; eso se sigue en el item del pod, no aca. Si alguien decide subir DEV a 17 eso es un item nuevo.