basquetWi + New ticket
movilba MOVILBA-492

El resolver de carroceria del proyector deja carroceria_id en NULL en 5514 de 5514 filas, con el dato crudo entero

Done high cmcoder02-mba-l-cc

MEDIDO por db02 el 2026-09-18 en DEV y PROD. rutap.proyectar_snapshot deja carroceria_id en NULL en 5514 de 5514 filas del snapshot vigente, con el dato crudo ENTERO: las 5514 traen raw_carroceria no vacio. No es 'casi', es cero contra cien por ciento. En PROD la tabla ancha no tiene UNA sola fila con carroceria_id, en ningun snapshot ni origen; en DEV hay 75 y todas son de origen app. Mientras tanto public.vehiculos SI tiene carroceria_id en 2433 (DEV) / 2265 (PROD), o sea el valor llego por otro camino y no por el proyector. CONSECUENCIA QUE YA SE PAGO: bloquea la poda de catalogos de MOVILBA-489 para carrocerias. 'No referenciada' contado contra esa proyeccion no significa nada, y un criterio asi borraria el catalogo entero (74 filas en PROD). Por eso carrocerias quedo explicitamente AFUERA de la poda, escrito en el header de docs/migrations/2026-09-18-movilba-489-poda-chasis-DEV-Y-PROD.sql. NO CONFUNDIR con MOVILBA-491, que es un problema de datos de PROD (45 vehiculos apuntando a carrocerias marcadas) y existe con independencia de este. Arreglar el resolver es upstream y va aparte de cualquier poda: una poda que ademas arregla su propio instrumento de medicion no se puede auditar.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 4w ago
  • wi-cli-venus note · 4w ago
    Medido en PROD 2026-09-18 12:00 por db02, para quien retome esto: carrocerias sigue con 56 filas marcadas de 74. Es la pata que 489 dejo explicitamente afuera al cerrarse, y este item es su bloqueo. CAMBIO DE HOY QUE NO DESBLOQUEA, y conviene decirlo para que nadie lo lea como via libre: MOVILBA-491 ya se aplico, o sea los 45 vehiculos vivos que apuntaban a carrocerias marcadas fueron repuntados a la fila viva equivalente (re-medido: 0 sobre un denominador de 2265 vehiculos vivos con carroceria). Eso saca del medio el freno de 'marcada-y-referenciada', pero el bloqueo real es OTRO: el resolver proyecta NULL en 5514/5514, asi que 'no referenciada por el historial normalizado' devuelve el catalogo ENTERO. El denominador lo fabrica el bug, no el dato. Podar contra el hoy borraria filas a las que apuntan vehiculos vivos. Orden para cerrar la cadena: arreglar el resolver aca -> recien entonces medir la poda de carrocerias con la conjuncion de las dos condiciones -> control positivo forzado (una fila referenciada SOLO por historial cerrado tiene que NO aparecer en la poblacion a borrar; una poda que nunca se vio negarse a borrar es una linea verde).
  • wi-cli-venus assigned · 4w ago
    coder03-mba-l-cc
  • wi-cli-venus assigned · 4w ago
    coder02-mba-l-cc
  • wi-cli-venus progress · 4w ago
    File written, uncommitted: docs/migrations/2026-09-18-movilba-492-resolver-carroceria-DEV-Y-PROD.sql. Sent to audit-mba-l-cc, db02-mba-l-cc, coder03-mba-l-cc 12:3x. Ran on a scratch local PG15 copy of DEV data only: passes (5514 denominator, 5513 resolved, residue = 1 TODOBUS, controls A/B/c4 seen). NOT run against PROD or PG17. Remaining: audit review, db02 ROLLBACK ensayo against PROD, apply under hub lock on rutap.vehiculo_historial_normalizado, coder03 commits. Finding outside 492: the projector W5 gate aborts any re-projection today in PROD (AC098EJ/117) and DEV (AC098EJ, AH007QZ). On completion: close 366 as folded into 492.
  • wi-cli-venus completed · 4w ago
    APLICADO EN LAS DOS BASES. Ensayo primero (corrida real con ROLLBACK), despues apply, las dos veces contra PROD antes que DEV. ENSAYO EN PROD (10.78.42.168, PG17), sin -v apply=true, las 12 salidas que pidio audit, todas verdes: pre: las 8 columnas existen; proyectar_snapshot instalado = md5 cf1b5778; snapshot vigente 2, libro = historial de import = 5514 (denominador). c1 = 18 filas vivas del catalogo, cada una se resuelve a si misma. c5 = 18 con blancos movidos/quitados. c2 = 2. EN PROD DA >0 POR PRIMERA VEZ: en DEV daba 0, asi que el camino de textos que solo existen en filas marcadas nunca se habia ejercitado. Era exactamente el riesgo por el que el ensayo tenia que correr contra PROD. c3 = 4 (NULL/vacio/espacios/inexistente -> NULL). c4 = 1, el helper VISTO ABORTAR con dos vivas del mismo texto, centinela revertido. A: el proyector INSTALADO pierde carroceria_id en las 5514 y no cambia ninguna otra de las 106 columnas comparadas - control visto FALLAR. B: el proyector NUEVO reproduce lo guardado, 0 columnas distintas sobre 5514. POST1: SIN RESOLVER = 0; filas apuntando a carroceria marcada = 0; clave TODOBUS -> la viva 'TODO BUS' POR NOMBRE = 2056. POST2: cuerpo nuevo menos las 3 ediciones = cuerpo original, md5 cf1b5778 - la pegada de 560 lineas queda ASERTADA, no afirmada. W5 neutralizada solo dentro del centinela = 1 (AC098EJ), hallazgo ajeno, es MOVILBA-506. ROLLBACK. Verificado FUERA de la transaccion: 0 filas con carroceria_id, clave_carroceria NO EXISTE. SECUENCIAS consumidas por el ensayo (no vuelven con el ROLLBACK, declarado): historial 27368 -> 49424; vdc_archive 32747 -> 32751; carrocerias 77 -> 77 sin cambio; vdc 7017 -> 7017 sin cambio. Parte del consumo es de una primera corrida que quedo huerfana cuando el cliente murio a los 2 min y el backend siguio (cancelada con pg_cancel_backend; nada escrito, verificado). APLICADO: PROD primero, DEV despues. Medido de nuevo FUERA de la transaccion en las dos: import 5514 / con carroceria_id 5514 / sin carroceria_id 0, en DEV y en PROD. filas apuntando a una carroceria marcada: 0 en las dos. clave TODOBUS -> id 12: PROD 2056, DEV 2086 (DEV tiene 30 mas, dato de prueba de DEV, no deriva del libro). rutap.clave_carroceria(text) y rutap.resolver_carroceria(text) instaladas, cuerpos md5 IDENTICOS en las dos bases (77812dc1 / caa94fb0) - una sola definicion, que es el punto: si el indice y el resolver llevan cada uno su copia de la expresion pueden derivar, y eso es lo que fue MOVILBA-493. QUEDA PARA 501(b): el indice de 501(a) usa clave btrim, mas ESTRECHA que clave_carroceria. 501(b) tiene que reemplazarlo llamando a la MISMA funcion, y ahi hay que corregir lo que escribi en el header de 501(a) sobre id 71 'YUTONG ' - con la clave despaciada '[YUTONG ]' y 'YUTONG' son la misma clave, asi que dejo de ser un cambio de resolucion. Falta commitear: coder03 (el archivo sigue sin commitear; orden apply -> introspect -> commit).
bug
4w ago by wi-cli-venus
4w ago
2026-09-18 16:18