creado_en no es orden de escritura en 2441 de 4052 filas de vehiculo_historial: 8 consumidores lo leen como recencia; el dano visible es chico (2 vehiculos mal en el export) y el arreglo barato solo alcanza a 12 de 134
MEDIDO EN PROD POR db-mba-l-cc Y db02-mba-l-cc (08-21, dos corridas independientes): vehiculo_historial.creado_en NO significa 'cuando se escribio la fila' para la mayoria de la tabla. Se parte limpio por loader: import-rutap-2026-08-14-prod 2274/2274 backdateadas, import-movilba-19 164/164, import-movilba-24 3/3 - en todas creado_en::date = fecha_alta POR CONSTRUCCION. Contra eso system_import 0/1599 y movilba-104-prod 0/7 llevan timestamp de ingesta real. Total 2441 de 4052 (60%) guardan una fecha de NEGOCIO en una columna que todo el mundo lee como fecha de REGISTRO. Consecuencia dura: las filas de rutap tienen creado_en MENOR e id MAYOR que las de system_import, o sea que creado_en corre AL REVES del orden de insercion cuando se cruzan loaders. GREP DEL CODIGO HECHO POR coder-mba-l-cc (08-21), 8 consumidores sobre vehiculo_historial, ninguno documentado como consciente del problema: 1. drizzle/schema.ts:1644 - v_vehiculos_export: (SELECT max(h.creado_en) ...) AS ultima_modificacion. ES LA PEOR: columna VISIBLE PARA EL USUARIO en el export, y para el 60% de las filas informa la fecha del tramite y no la de modificacion. Un vehiculo tocado ayer puede mostrar 2025. 2. drizzle/schema.ts:1983 - v_vehiculos_dashboard: fecha_estado = COALESCE(lh.creado_en, v.creado_en) y ultima_modificacion = GREATEST(...). Mismo defecto, otra superficie. 3. drizzle/schema.ts:1762 - v_vehiculos_hist_ultimo, clave terminal creado_en DESC. YA ES MOVILBA-73, no re-arreglar aca. 4. drizzle/schema.ts:1672 - v_vehiculo_historial: ORDER BY COALESCE(fecha_alta, creado_en::date) DESC, creado_en DESC. El segundo termino es funcionalmente dependiente del primero en las 2441 backdateadas: un desempate que NO PUEDE DISPARAR. 5. drizzle/schema.ts:1873 - v_vehiculos_cadena_chasis: row_number() OVER (... ORDER BY COALESCE(ultimo_evento, creado_en::date), creado_en, o.id). Tiene id como terminal, asi que es determinista, pero ordena por fecha de negocio creyendo ordenar por registro. 6. drizzle/schema.ts:2045 - v_vehiculos_detalle: el jsonb de historial sale ORDER BY vh.creado_en DESC, vh.id DESC. Determinista, semantica equivocada: es el orden que ve la ficha. 7. src/repositories/vehiculos.ts:669 - .orderBy(desc(vehiculoHistorial.creadoEn)) PELADO, sin desempate. Determinismo cero ademas de la semantica. 8. src/actions/vehiculos.ts:281-282 - COALESCE(fechaExpediente, creadoEn::date) DESC, creadoEn DESC. Igual que 4: el desempate no puede disparar. El comentario de arriba dice que cae a 'la fecha de registro', que es justo lo que creado_en no es para el 60%. NO ES INCIDENTE HOY salvo por 1 y 2, que son cosmeticos-pero-visibles; el resto ordena mal sin romper. LO QUE HAY QUE DECIDIR ANTES DE TOCAR NADA: si la columna correcta de recencia es h.id (unica que sigue el orden real de insercion), o si hace falta una columna nueva de ingesta y backfillearla por loader. Esa decision es de Elazar/Eugenia para 1 y 2 porque cambia lo que el usuario ve. No tocar mientras 73 este en vuelo - comparten la tabla y coder02-mba-l-cc esta editando la vista de 3. TAMBIEN: una fila tiene creado_por = 20394678369, un numerico pelado con forma de CUIT en una columna que en el resto guarda nombres de loader. Rompe cualquier GROUP BY por loader. Chico, pero es la misma familia y ya esta medido.
Activity
-
CORRECCION DE DOS CIFRAS DE MI PROPIO TEXTO, las dos en direccion segura, medidas en prod por db02-mba-l-cc y db-mba-l-cc a las 10:38. 1) EL 60% ES DE LA TABLA, NO DEL EXPORT. En v_vehiculos_export la cifra es 134 de 1738 vehiculos (7.7%) cuya ultima_modificacion sale de una fila backdateada. El 60% de filas colapsa a 7.7% de vehiculos porque la expresion es max(): system_import estampo 1599 filas en 2026-06-22 10:50:32, y ese timestamp real le gana a casi cualquier fecha de negocio backdateada. O sea que un vehiculo solo muestra el defecto cuando TODAS sus filas son backdateadas. max() esta ENMASCARANDO el defecto, no evitandolo - lo cual importa porque cualquier cambio que toque esas filas puede destapar los otros 1604. 2) 'un vehiculo editado ayer puede mostrar 2025' NO SE OBSERVA y hay que sacarlo. El minimo real de ultima_modificacion en prod vivo es 2026-01-26. El modo de falla es real, la ilustracion lo exageraba, y quien vaya a verificar no va a encontrar ningun 2025 y puede concluir que el item entero esta mal. Usar el piso medido. 3) NO CONFUNDIR CON LA OTRA CIFRA. db-mba-l-cc midio que max(creado_en) y el creado_en de la fila de id MAS ALTO discrepan en 1274 de 1738 (73%), con brechas de 10 horas a 400 DIAS, y en las DOS direcciones - la columna puede leer mas NUEVA que la verdad, no solo mas vieja. Eso NO es 'cuantos estan mal': es cuanto cambiaria de fila elegida si se pasara a un proxy de orden de escritura. Son dos preguntas distintas sobre la misma columna y no se citan intercambiables: 134 = cuantos muestran hoy una fecha de tramite; 1274 = cuantos cambiarian de fila con el arreglo barato. 4) ADVERTENCIA SOBRE EL ARREGLO BARATO, de db-mba-l-cc: h.id es un buen proxy de ORDEN DE ESCRITURA, pero el creado_en al que apunta SIGUE siendo una fecha de negocio en el 60% de las filas. Cambiar ultima_modificacion a 'creado_en de la fila de id maximo' cambia QUE fila se elige sin arreglar QUE se lee de ella. Solo un timestamp de ingesta real, backfilleado por loader, contesta 'cuando se modifico esto'. Que nadie shipee la version barata creyendo que es el arreglo. 5) LA VERIFICACION SE HACE CONTRA PROD, NO CONTRA drizzle/schema.ts. db02-mba-l-cc re-verifico la definicion en la base porque schema.ts es salida de introspect y ningun gate lo consume: un hallazgo que solo vive ahi todavia no es un hallazgo sobre la base. La expresion esta en prod, confirmada.
-
COLISION DE SECUENCIA CON MOVILBA-109 OPCION D - hallada por db02-mba-l-cc, no la habia visto nadie. consumo y ultima_modificacion viven EN LA MISMA VISTA, v_vehiculos_export. La opcion D de 109 cambia consumo de text a numeric, y un cambio de TIPO de columna no se puede hacer con CREATE OR REPLACE VIEW: exige DROP+CREATE. O sea que quien ejecute D reescribe la definicion ENTERA de la vista, incluida la expresion de ultima_modificacion. Consecuencia: 113 y 109-D NO son independientes aunque se lean como dos columnas sin relacion en dos tickets distintos. Si 113 entra primero, D lo revierte en silencio. Si D entra primero, 113 hay que re-cortarlo contra la definicion nueva. Necesitan UN solo owner y un orden explicito. Esto se suma a la condicion dura que ya tenia 109 (export y ficha juntos o es una regresion) y es una razon mas para que D no salga como arreglo aislado. Y para el brief a Elazar: son DOS defectos distintos en la MISMA vista de cara a GCABA, encontrados el mismo dia por causas no relacionadas - 109/D (fecha_alta prestada de otro dominio via el join por chasis, 155 de 1738) y este. Se presentan juntos, no porque haya que arreglarlos juntos, sino porque 'el export tiene una columna mal' y 'el export tiene dos columnas mal por causas distintas' son mensajes distintos sobre cuanto se puede confiar en ese artefacto.
-
Contra-medicion de las DOS superficies visibles, en PROD 2026-08-21 10:40 (coder02-mba-l-cc). Las dos cifras se achican mucho, la segunda vista NO es la que dice el item, y aparece un acoplamiento con MOVILBA-42 que nadie habia nombrado. 1) LA SEGUNDA SUPERFICIE NO EXISTE CON ESE NOMBRE. No hay ninguna relacion '%dashboard%' en prod, ni la cadena 'vehiculos_dashboard' en drizzle/schema.ts ni en src/. La vista de schema.ts:1983 es v_vehiculos_api_public - el contrato publico de parque-movil (SOTAMIT), no una pantalla de GCABA. Cambia el publico y cambia el riesgo: es un contrato congelado, no una columna de una tabla interna. 2) EL EXPORT: 134 de 1738, no el 60%. El 60% es una propiedad POR FILA de vehiculo_historial; el export agrega con max(h.creado_en) POR VEHICULO, y las filas de system_import (timestamps de ingesta reales, 2026-06-22..08-05) dominan el max en casi todos. Medido: 134/1738 (7,7%) muestran una fecha de negocio. De esos 134, **132 no tienen NINGUNA fila con timestamp real** - todas sus filas vinieron de un loader que backdatea, asi que no hay una verdad que se este tergiversando: la columna muestra la unica fecha registrada. Solo 2 (vehiculo_id 4189 y 3502) muestran una fecha distinta de un timestamp de ingesta que SI existe en la misma tabla, y la muestran 46 y 49 dias MAS NUEVA, no mas vieja. 'Un vehiculo editado ayer puede mostrar 2025' tiene CERO instancias: el valor mas viejo de todo el export es 2026-01-26. 3) v_vehiculos_api_public: 2 filas de 1738, y 1 sola anterior a 2026. Usa GREATEST(v.creado_en, COALESCE(lh.creado_en, v.creado_en)), y vehiculos.creado_en SI es un timestamp de ingesta real (24 valores distintos, 2025-12-08..2026-08-14), asi que el GREATEST rescata casi todos los casos. El minimo de 2025-12-08 de esa vista viene de vehiculos.creado_en, que es correcto, no del backdating. 4) EL HALLAZGO QUE IMPORTA, y es de OTRO ticket: el CTE de v_vehiculos_api_public se llama 'latest_historial' y NO deduplica - es SELECT vehiculo_id, estado_id, creado_en FROM vehiculo_historial WHERE borrado_en IS NULL, sin DISTINCT ON, sin ORDER BY, sin GROUP BY. Se joinea 1:1 asumiendo una sola fila viva por vehiculo. Hoy eso se cumple (vehiculos con >1 fila viva = 0; la vista da 1738 filas / 1738 vehiculos distintos) y lo sostiene UNICAMENTE el indice uq_vehiculo_historial_activo ON (vehiculo_id) WHERE borrado_en IS NULL. **MOVILBA-42 propone DROPear ese indice** - es el primer paso del modelo append-only. Dropearlo multiplicaria filas en el contrato publico de la API, en silencio y sin que ninguna vista lo avise. Eso es un prerrequisito de 42 que hasta ahora no estaba en su lista. Otras 11 vistas tocan vehiculo_historial sin DISTINCT ON y comparten la exposicion, SIN VERIFICAR una por una - solo la de api_public esta leida: v_vehiculo_cadena, v_vehiculo_historial, v_vehiculos_detalle, v_vehiculos_export, v_vehiculos_lineas_entidades, v_db_users_footprint_detalle y las 5 v_audit_*. Nombrarlas es scoping, no un hallazgo; cada una necesita su lectura. NO TOQUE NADA. 113 es de coder-mba-l-cc y 42 esta bloqueado. Solo SELECT.
-
CORRECCION DE NOMBRE - INVENTE UNA VISTA QUE NO EXISTE. Hallado por coder02-mba-l-cc, verificado por mi: 'v_vehiculos_dashboard' NO EXISTE. Cero apariciones en todo el repo (src, drizzle, sql) y ninguna relacion que matchee en prod. La vista de schema.ts:1983 es v_vehiculos_api_public. Deduje el nombre del contenido en vez de leer la declaracion, y quien grepee el nombre que puse no va a encontrar nada y va a concluir que el item esta mal. Y NO ES UNA PANTALLA DE GCABA: v_vehiculos_api_public es el contrato publico de parque-movil/SOTAMIT. Audiencia distinta y riesgo distinto - un contrato externo congelado, no una columna interna. Eso cambia quien decide sobre ella. MAGNITUD, otra vez a la baja y otra vez medida por coder02-mba-l-cc en prod 10:40: - export: de los 134, CIENTO TREINTA Y DOS no tienen NINGUNA fila con timestamp real. O sea que no hay una verdad que se este informando mal: la columna muestra la unica fecha que existe. Solo DOS vehiculos (4189 y 3502) muestran una fecha que difiere de un timestamp de ingesta presente en la misma tabla, y la muestran 46 y 49 dias MAS NUEVA. - api_public: 2 filas de 1738. GREATEST(v.creado_en, ...) rescata casi todo porque vehiculos.creado_en SI es timestamp de ingesta real. Su minimo 2025-12-08 sale de ahi y es CORRECTO, no backdateo. - direccion: um_actual > um_maxid en 1274 casos y MENOR en CERO (db02-mba-l-cc). Nunca lee mas vieja. Mi 'puede mostrar 2025' tiene cero instancias. O sea: el defecto existe en las dos superficies y es cosmetico en las dos, y mis dos ilustraciones lo exageraban en un orden de magnitud y en tres respectivamente. El item se sostiene por el 12 (cuantos cambiarian de fila con el proxy h.id) y por el 2 (cuantos informan mal una verdad que la tabla tiene), no por el 60% ni por el 134.
-
creado_en no es orden de escritura en 2441 de 4052 filas de vehiculo_historial: 8 consumidores lo leen como recencia; el dano visible es chico (2 vehiculos mal en el export) y el arreglo barato solo alcanza a 12 de 134
-
3
-
db02-mba-l-cc / db
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:05 ART — SELECT-only installed-object check in DEV movilba_dev and PROD movilba: to_regclass('public.vehiculo_historial') is NULL in both; the ticket's historical population/column premise cannot be reverified in that retired table. Current replacement rutap.vehiculo_historial_normalizado has 5528 nondeleted imported rows in each base, but this sweep did not exercise the ticket-specific invariant against it. Status unchanged; do not apply an old-table repair.
-
db03-mba-l-cc / db
-
db03 2026-10-08: premise fully superseded, closing. This ticket's entire measurement (60% of 4052 rows with business-date-backdated creado_en, 8 named consumers reading it as recency) was taken against public.vehiculo_historial, confirmed gone (to_regclass NULL, same finding as db04 2026-09-24's sweep, re-verified here) - replaced 2026-08-14 by rutap.vehiculo_historial_normalizado, itself rebuilt again since (current snapshot 11, loaded 2026-10-06). THE DECISION THIS TICKET ASKED FOR ("si la columna correcta de recencia es h.id... o si hace falta una columna nueva de ingesta y backfillearla por loader") IS MOOT: the rebuild gives creado_en exactly the property requested - a genuine per-load ingestion timestamp, not a per-row business date. Measured: all 5558 live rows of the current snapshot share ONE creado_en value (the single projection-run timestamp from rutap.proyectar_snapshot's execution), not 2441 backdated business dates mixed with real timestamps. There is no more "60% of rows disagree with insertion order" because every row's creado_en IS the insertion/projection timestamp. The two visible-surface defects this ticket flagged as real (export ultima_modificacion, api_public fecha_estado/ultima_modificacion) were independently fixed this session via other tickets: v_vehiculos_export rebuilt under MOVILBA-442 (closed), and the MOVILBA-12 closure (this session) confirmed v_vehiculos_api_public's chain is on the deterministic rank-based source with creado_en 0% overloaded today. The creado_por CUIT-shaped-value anomaly ("20394678369 en una columna que guarda nombres de loader") does not reproduce in the current table: rutap.vehiculo_historial_normalizado.normalizado_por holds exactly one clean value, 'movilba-269' (the loader identity), across all live rows - no numeric/CUIT-shaped outliers. The 8 consumer line-references (drizzle/schema.ts:1644/1762/1672/1873/1983/2045, src/repositories/vehiculos.ts:669, src/actions/vehiculos.ts:281-282) are themselves stale: drizzle/schema.ts is introspection output and is regenerated per project convention, so those specific line numbers describe a schema snapshot that predates the 08-14 and subsequent rebuilds and cannot be re-verified as written. Not re-measured: whether any CURRENTLY installed consumer has its own independent ordering defect against the rebuilt table - that is MOVILBA-12's scope (closed this session with its own fresh 5-view audit), not 113's. 113 specifically was about creado_en's overloaded semantics in the retired table; that semantics is gone with the table.
-
Premise superseded: retired table's creado_en overload doesn't exist in its replacement (rutap.vehiculo_historial_normalizado) - all live rows share one genuine ingestion timestamp per load, not backdated business dates. Both visible-surface defects already fixed via MOVILBA-442/12 this session.
-
audit pass: re-checked table retirement + creado_en uniformity on PROD
payload
{"scope":"re-checked table retirement + creado_en uniformity on PROD","outcome":"pass","evidence":"to_regclass('public.vehiculo_historial') is NULL (table gone); current snapshot's rutap.vehiculo_historial_normalizado has exactly 1 distinct creado_en value across all rows","reportRef":null}