raw_* vacias en PROD: la causa NO es la migracion (en DEV la misma etiqueta 202 las deja pobladas), asi que es especifica del entorno

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus titleChanged · 5w ago
  PROD no conserva NADA de la procedencia del libro: las 39 columnas raw_ estan NULL en las 5388 filas importadas
• wi-cli-venus verified · 5w ago
  BARRIDO COMPLETO por db02-mba-l-cc: son TREINTA Y NUEVE columnas, no una. PROD, origen=import, 5388 filas: las 39 columnas raw_ estan NULL en las 5388, poblado/total 0/5388 treinta y nueve veces, sin excepcion. DEV, 21514 filas: raw_tipo 21514/21514. Por eso el titulo cambia: una columna es un bug de mapeo, treinta y nueve es una corrida que NUNCA ESCRIBIO EL BLOQUE. RETRACTACION DE LA CAUSA, hecha por db02 sobre su propio mensaje anterior y propagada por mi a Elazar como si fuera medicion: NO esta sostenido que el valor sobreviva la carga y se caiga camino a la historia normalizada, ni que sea la clase de asimetria de MOVILBA-344. Eso era un MECANISMO afirmado desde un CONTEO. Se retira. Vale la regla: un conteo mide una poblacion, jamas una causa. LO QUE SI ESTA MEDIDO. Las filas de import de PROD salen de UNA SOLA corrida de normalizacion: normalizado_por movilba-202, 2026-09-07 12:07:46, las 5388 identicas al segundo. DEV tiene TRES corridas - movilba-203 (09-04, 5370), movilba-202 (09-06, 10756) y movilba-269 (09-08 01:40, 5388) - y raw_ esta poblado en todas, INCLUIDA la de movilba-202. Mismo tag, resultado opuesto en los dos entornos: eso es lo que hay que explicar. DERIVA DE ESQUEMA DESCARTADA, no buscar por MOVILBA-326: pg_attribute es identico en forma en los dos entornos - 109 columnas, raw_ ocupando attnum 60-98, 39 columnas. Las columnas YA EXISTIAN en PROD cuando corrio esa normalizacion; no se agregaron despues. No es un loader anterior a las columnas. SIGUIENTE PASO, y es lectura, no conteo: que invocacion produjo la corrida del 09-07 en PROD y si tenia el bloque raw_ disponible. Se contesta en tools/rutap-snapshot-to-postgres.py y en el historial de git alrededor del 2026-09-07. Nadie leyo el importador todavia. LA REPARACION ES UNA ESCRITURA SOBRE DATOS IMPORTADOS DE PROD y no esta pedida ni propuesta. Cuando llegue: la fuente sigue estando (rutap_rows.tipo 10756/10756), asi que un backfill es posible, pero solo es correcto si la identidad fila-a-fila entre rutap_rows y las filas normalizadas es DEMOSTRABLE. Ese gate se escribe ANTES de la escritura, no despues.
• wi-cli-venus note · 5w ago
  PARKED por orden de Elazar el 2026-09-08 06:03 CLI: "why are you working on prod?" - rige su regla permanente de no trabajar dos servidores a la vez, primero DEV y despues deployamos a PROD. Este item es un hallazgo SOLO DE PROD, asi que queda FILADO y QUIETO: no se lee el importador, no se hace arqueologia de git, no se disena reparacion y sobre todo NO SE ESCRIBE NADA. Se retoma cuando DEV este bien y toque el deploy a PROD, y aun ahi la reparacion necesita GO explicito de Elazar aparte. La medicion ya registrada NO se pierde y no hace falta rehacerla. Como llegamos aca, para que no se repita: yo pedi las mediciones "DEV y PROD por separado", asi que la deriva de alcance es mia, no del carril de base.
• wi-cli-venus titleChanged · 5w ago
  PROD no preserva procedencia: las 39 columnas raw_* quedan NULL en las 5388 filas importadas de vehiculo_historial_normalizado
• wi-cli-venus note · 5w ago
  db02 2026-09-08 06:0x: PARKED por coder02 (Elazar: no se trabaja PROD; DEV primero). Alcance corregido de 1 a 39 columnas. MEDIDO (PROD 10.78.42.168, PG 17.6, SELECT): las 39 columnas raw_* dan 0/5388 no-nulas en origen='import'. Sin excepciones. DEV (10.9.10.54, PG 15.17): raw_tipo 21514/21514. CORRIDAS DE NORMALIZACION: PROD tiene UNA sola, normalizado_por 'movilba-202' 2026-09-07 12:07:46, las 5388 identicas al segundo. DEV tiene tres - movilba-203 (09-04, 5370), movilba-202 (09-06, 10756), movilba-269 (09-08 01:40, 5388) - y raw_* esta poblado en las tres, INCLUIDA la de movilba-202. Mismo tag, resultado opuesto por entorno. DERIVA DE ESQUEMA DESCARTADA: pg_attribute identico en los dos entornos - 109 columnas, raw_* en attnum 60-98, 39 columnas. Las columnas EXISTIAN en PROD cuando corrio esa normalizacion; no se agregaron despues. No es la clase 326. RETRACTADO: dije que el valor 'sobrevive la carga y muere al entrar al historial normalizado' y lo llame clase 344. No esta sustentado - era un conteo, no un mecanismo. Lo unico medido es lo de arriba. LA FUENTE SIGUE VIVA: rutap.rutap_rows.tipo es no-nulo 10756/10756 en PROD, asi que un backfill es posible. NO propuesto. Si algun dia se hace: el gate es probar la identidad de fila entre rutap_rows y las filas normalizadas ANTES de escribir, no despues. SIN EJERCITAR: no lei tools/rutap-snapshot-to-postgres.py, no mire git alrededor del 2026-09-07, y no hay ninguna escritura. Reparar es escritura sobre datos importados de PROD y necesita GO explicito de Elazar ademas del desbloqueo.
• wi-cli-venus descriptionChanged · 5w ago
  was: Medido por db02-mba-l-cc el 2026-09-08, DEV 10.9.10.54 PG 15.17 y PROD 10.78.42.168 PG 17.6, SELECT only. Aparecio contestando una pregunta de presentacion (MOVILBA-360) y es mucho peor que ella. EL HECHO, con los dos lados del par. En rutap.vehiculo_historial_normalizado, filas origen='import': DEV tiene raw_tipo poblado en 21514 de 21514. PROD lo tiene poblado en 0 de 5388 - TODAS NULL - y sin embargo vehiculo_subtipo_transporte_id SI esta seteado. O sea que en PROD la historia conserva el id DERIVADO y perdio el valor que el libro escribio. DONDE SE PIERDE, acotado por medicion y no por lectura del codigo: la tabla de aterrizaje todavia lo tiene. rutap.rutap_rows.tipo esta no-nulo en 10756 de 10756 filas en PROD. Asi que el valor SOBREVIVE la carga y se cae en el camino hacia la historia normalizada. El tramo exacto no esta identificado todavia: nadie leyo el importador para decir en que linea se pierde. POR QUE IMPORTA, y no es cosmetico. La columna raw_* existe para preservar procedencia: es la que contesta "que decia el libro". Con raw_tipo en NULL, PROD no puede contestar esa pregunta para esta columna y solo queda nuestra derivacion, que es justamente lo que la columna estaba para poder auditar. La afirmacion "MovilBA es un espejo fiel del libro" es FALSA para esta columna en PROD hoy, y lo es en silencio: no hay error, no hay fila faltante, el id derivado se ve perfectamente bien. ES LA MISMA CLASE QUE MOVILBA-344: escritura asimetrica, donde una parte del registro se puebla y otra no, y la que no se puebla es justamente la evidencia. No se arregla con nada de 360, que es presentacion. LO QUE FALTA MEDIR, y es lo primero: si esto le pasa SOLO a raw_tipo o tambien a las otras 38 columnas raw_*. db02 lo dejo explicito como no ejercitado y pidio medirlo en vez de suponer que es una sola. Un solo caso es un bug; treinta y nueve es que el mecanismo de preservacion de procedencia no funciona en PROD. Se mide por columna, DEV contra PROD, poblado sobre total, y se reportan los PARES, no un conteo. DESPUES: leer el importador para nombrar el tramo donde se cae, y recien ahi decidir la reparacion. Ojo que reponer raw_tipo en PROD es una ESCRITURA sobre datos importados y necesita GO explicito de Elazar; no entra por la puerta de un fix de presentacion. NO EJERCITADO: nadie leyo el importador, no se midieron las otras 38 raw_*, cero escrituras.
• wi-cli-venus note · 5w ago
  DEJA DE ESTAR AISLADO EN PROD. Medido por db02-mba-l-cc el 2026-09-08 en DEV: la etiqueta de normalizacion movilba-202 - la misma cuya corrida en PROD dejo las 39 columnas raw_* en NULL - es en DEV la corrida que resuelve CERO chasis, sobre 5368 y 5388 filas de los snapshots 9 y 11, mientras movilba-203 y movilba-269 resuelven normalmente. Un mismo camino de normalizacion se saltea el bloque de procedencia Y el resolver de catalogo. Eso convierte la clase en OBSERVABLE EN DEV, medida sobre filas de DEV, asi que se puede investigar sin tocar PROD - que era exactamente lo que tenia este item aparcado. Sigue aparcado hasta que Elazar lo desaparque, pero el motivo del parking cambio: ya no hace falta PROD para avanzar. Ver MOVILBA-367. Falta establecer si movilba-202/203/269 son versiones de codigo o banderas de invocacion; nadie leyo el importer todavia.
• wi-cli-venus note · 5w ago
  DESAPARCADO por Elazar el 2026-09-08 ("unpark 361, work it in dev"). Primera medicion en DEV por db02-mba-l-cc, SELECT only, y MATA la hipotesis con la que lo desaparque. MI HIPOTESIS ERA: que movilba-202 fuera la migracion temprana y flaca que armo la tabla ancha sin el bloque raw_, que PROD se hubiera normalizado con ella y nunca re-corrido, y que entonces 361 no fuera corrupcion sino una corrida que no llego. La apoye en un conteo de grep sobre los archivos: 'raw_' aparece 2 veces en el archivo de 202, 41 en el de 203 y 64 en el de 269. ESTA FALSIFICADA. En DEV, las filas con normalizado_por='movilba-202' tienen raw_* POBLADAS. Sobre las 10756 filas con esa etiqueta, NINGUNA de las 39 columnas raw_ esta vacia - ni una. Las cuatro mas ralas son raw_expte_baja 7005/10756, raw_fecha_baja 7552, raw_observaciones 7909 y raw_expte_alta 9304, y esa ralitud es la normal (un periodo abierto no tiene expediente de baja). db02 lo verifico por DOS caminos independientes justamente por ser la respuesta incomoda: un least()/greatest() sobre los 39 conteos por corrida, y un unpivot por columna contando columnas en cero, que devuelve 0. O SEA QUE LA MISMA ETIQUETA DE MIGRACION produjo raw_ completas en DEV y 0 de 5388 en las 39 columnas en PROD. La causa NO es de version, es DE ENTORNO, que es la rama peor. Y mis conteos de grep dejan de ser evidencia y pasan a ser algo que HAY QUE EXPLICAR: el archivo con 2 menciones produjo 10756 filas DEV completas. DENOMINADOR de la medicion, 21514 filas origen='import' en DEV: movilba-202 / snapshot 9 / 5368 filas / raw_ pobladas entre 3492 y 5368 / chasis resueltos 0 movilba-203 / snapshot 10 / 5370 filas / entre 3495 y 5370 / 50 movilba-202 / snapshot 11 / 5388 filas / entre 3513 y 5388 / 0 movilba-269 / snapshot 12 / 5388 filas / entre 3513 y 5388 / 52 SE SEPARA DE MOVILBA-367, y esto es lo importante: parecian una causa con dos sintomas y no lo son. El sintoma de CHASIS sigue a la migracion (202 resuelve cero en los dos entornos) y queda en 367, confirmado en DEV. El sintoma de raw_ NO sigue a la migracion y se queda solo en este item. ESPACIO DE CANDIDATOS, nombrado como espacio y no como hallazgo: que contra PROD se haya corrido un archivo distinto bajo la misma etiqueta; que una pasada posterior en DEV haya reescrito las columnas sin tocar normalizado_por; o una diferencia del lado de PROD al momento de escribir. Nadie leyo todavia los tres archivos de migracion ni su historia de git. EL PROXIMO PASO, que db02 nombro y es el correcto ANTES de tocar ningun archivo: comparar normalizado_en contra las fechas de las migraciones. Si una pasada posterior en DEV reescribio raw_* sin actualizar normalizado_por, entonces las filas '202' de DEV no son lo que 202 produjo y la falsificacion de arriba esta midiendo otra cosa. Es checkeable en DEV. NO EJERCITADO: PROD (deliberadamente, cero consultas), los tres archivos de migracion, la historia de git, y por donde se alcanza el resolver (ninguno de los tres archivos nombra chasis_resolver).
• wi-cli-venus titleChanged · 5w ago
  raw_* vacias en PROD: la causa NO es la migracion (en DEV la misma etiqueta 202 las deja pobladas), asi que es especifica del entorno
• wi-cli-venus note · 5w ago
  SE CAE LA FALSIFICACION PROPIA, y aparece un mecanismo. Medido por db02-mba-l-cc, DEV only, SELECT only. El chequeo que ellos mismos propusieron disolvio su resultado en vez de endurecerlo, que es para lo que servia. 1. normalizado_por NO NOMBRA A LA PASADA QUE ESCRIBIO LA FILA. Por corrida, normalizado_en contra el creado_en de la propia fila: snapshot 9, movilba-202: normalizado_en 2026-09-06 05:26:19.163153 / creado_en 2026-09-06 05:33:28.488067 snapshot 10, movilba-203: normalizado_en 2026-09-04 22:50:00.180938 / creado_en 2026-09-06 05:33:28.488067 snapshot 11, movilba-202: normalizado_en 2026-09-06 05:28:00.339675 / creado_en 2026-09-06 05:33:28.488067 snapshot 12, movilba-269: normalizado_en 2026-09-08 01:40:32.533281 / creado_en 2026-09-08 01:40:32.533281 Cada corrida tiene UN solo normalizado_en distinto: es una constante estampada, no una hora por fila. Y las filas de los snapshots 9, 10 y 11 se crearon TODAS en el mismo instante, 2026-09-06 05:33:28.488067, POSTERIOR a todos esos normalizado_en - el de 203 por un dia y medio. O sea que esas filas las escribio UNA pasada del 09-06 05:33:28 que llevo normalizado_por y normalizado_en COMO DATO. Las filas '202' de DEV no son lo que produjo 202. Se RETIRA la afirmacion "movilba-202 puebla raw_ en DEV": mide estado post-reescritura y no falsifica nada. El unico snapshot auto-consistente es el 12, donde normalizado_en es igual a creado_en al microsegundo. 2. HAY UN MECANISMO SOLO-DEV PARA EL BLOQUE raw_. Existe docs/migrations/2026-09-03-movilba-202-raw-fidelity-corrective-DEV.sql: un correctivo bajo LA MISMA etiqueta 202 que hace ADD COLUMN IF NOT EXISTS de las columnas raw_ y despues las rellena con UPDATE rutap.vehiculo_historial_normalizado ... FROM rutap.rutap_rows. Abre con una guarda que hace RAISE salvo que current_database() = 'movilba_dev'. Es decir: existe una migracion que mete los valores raw_ en DEV y que SE NIEGA POR DISENO a correr contra PROD. Es UN mecanismo, todavia no EL mecanismo: su fecha es 09-03 y las filas en cuestion se crearon el 09-06, asi que no puede ser lo que poblo ESAS filas. Lo que si establece es que el bloque raw_ llego a DEV por un correctivo y no por la migracion ancha - que es exactamente por que el grep del archivo ancho de 202 encontraba 2 menciones y los datos igual aparecian poblados. Reconcilia el texto con el comportamiento. 3. LO QUE FALTA, y nada de esto es de hoy: identificar QUE corrio el 09-06 05:33:28 y si es siquiera un archivo en disco; y despues si el correctivo, o un equivalente, corrio alguna vez contra PROD. Las dos son lecturas de DEV y del repo. Nadie leyo las tres migraciones anchas de punta a punta ni el correctivo mas alla de su guarda y sus UPDATE. Ver MOVILBA-370: los seis archivos de migracion involucrados NO ESTAN TRACKEADOS EN GIT.
• wi-cli-venus note · 5w ago
  SE RETIRA EL PUENTE CON MOVILBA-367. Al re-derivar 367 sobre creado_en, db02-mba-l-cc encontro que los snapshots 9, 10 y 11 los escribio una unica pasada y que dentro de ella el 10 resuelve chasis y el 9 y el 11 no. La etiqueta normalizado_por y el snapshot son colineales, asi que no se puede atribuir el comportamiento a la corrida. Por lo tanto la frase que escribi aca - que un mismo camino de normalizacion se saltea el bloque de procedencia Y el resolver de catalogo - NO SE SOSTIENE y se retira. Nunca fue una medicion: fue una lectura de dos sintomas que compartian una etiqueta. Este item queda SOLO con el sintoma de raw_ en PROD, sin relacion probada con el de chasis. El candidato mas fuerte sigue siendo el correctivo docs/migrations/2026-09-03-movilba-202-raw-fidelity-corrective-DEV.sql, que rellena raw_ y hace RAISE salvo que current_database() sea 'movilba_dev' - una migracion que por diseno no corre en PROD. Falta establecer si ese archivo, o un equivalente, explica las filas concretas, y su fecha (09-03) no cuadra con la creacion de las filas (09-06).
• wi-cli-venus note · 4w ago
  RE-MEDIDO 2026-09-18 por db02 (delegado por researcher). ARREGLADO, y medido sobre LAS 39 COLUMNAS, no sobre una. El item aviso que 'una columna es un bug de mapeo; treinta y nueve es que la preservacion de procedencia no ocurrio', asi que se recorrio pg_attribute y se conto cada raw_* por separado: 39 columnas raw_* encontradas, CERO totalmente vacias, en DEV y en PROD. No se extrapolo de raw_tipo. raw_tipo puntual: 5514 de 5514 poblado en PROD (el item media 0 de 5388) y 5514 de 5514 en DEV. CORRIDAS DE NORMALIZACION: ahora las dos bases tienen UNA sola y es la MISMA etiqueta, movilba-269 con 5514 filas cada una (PROD 2026-09-17 12:54, DEV 2026-09-17 13:20). El item describia PROD con una unica corrida movilba-202 que perdio el bloque entero mientras DEV tenia tres con raw_* poblado; esa asimetria ya no existe. La reproyeccion de 269 lo resolvio. Nota de alcance: el item estaba PARKED por la regla de Elazar de no tocar PROD hasta que DEV estuviera bien. No hizo falta ninguna escritura especifica - lo arreglo el camino normal de import/proyeccion. RECOMENDACION: cerrar. No lo cierro yo.
• wi-cli-venus completed · 4w ago
  Cerrado por db02 2026-09-18: recorridas las 39 columnas raw_* desde pg_attribute una por una, CERO totalmente vacias en las dos bases (el item media 0 de 5388 en PROD). Las dos bases corren ahora una unica normalizacion con la misma etiqueta movilba-269, 5514 filas cada una. Lo resolvio la reproyeccion, sin escritura especifica. Se pide doble chequeo a audit-mba-l-cc.