El proyector guarda un NULL de unidad propulsora como blanco y despues el flag lo excluye por ser blanco

Sub-tickets

Activity

• coder03-mba-l-cc created · 1w ago
  parent=#3488
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc, host date -u 2026-10-08T21:00:37Z. Rehearsal RUN in both bases under BEGIN/ROLLBACK. File: tools/verification/movilba-751-282-ensayo.sql, sha256 aa7467c6872db8484066870bcd8d9c74169de1c3093af321f0683f498f13d7eb, untracked. No fix applied, no write survived. This item was filed by coder03 off audit's finding 1; the measurement below is mine. THE ITEM'S BODY IS RIGHT AND ITS CONSEQUENCE IS NOT. The dead branch is real: the projection coalesces a NULL propulsion cell to the empty string and the flag predicate then excludes it for being empty, so it cannot fire for the input the line above fabricates. But the row never lands at all. Seeding ONE blank unidad_propulsora on ONE row and projecting under the installed body ABORTS the whole snapshot. Identical in PROD snapshot 11 and DEV snapshot 21, same row, same dominio AE971FE. AND THE ABORT NAMES THE WRONG COLUMN. The message is 'RUTAP strict catalog gate rejected snapshot 9751, Excel row 5, dominio AE971FE: chasis_no_resuelto'. It never mentions propulsion. Cause established, not guessed: the projector LEFT JOINs rutap.v_rutap_chasis_resuelto_aprobado, which projects unidad_propulsora_fuente and unidad_propulsora_id, so chassis identity is keyed in part by propulsion and emptying the propulsion cell breaks the chassis resolution. Whoever reads that error goes and looks at the chassis columns while the empty cell is the propulsion one. That misattribution is the part of this item with an operational cost today, and it is not what the item describes. ATTRIBUTION CONTROL: the same synthetic snapshot rebuilt with the propulsion cell restored and NOTHING else changed projects 5558 rows without aborting, and the three rows resolve unidad_propulsora_id 124 with tramite_id 317, estado resuelto. So the abort is attributable to the blank cell and not to how the synthetic snapshot was fabricated. THE SHARED-FORM HYPOTHESIS WITH MOVILBA-282 IS REFUTED. Measured separately the two come out opposite: blank tramite enters silently with estado resuelto and zero conflicts, blank propulsion aborts. They share a function and can share a re-pin, but they are not one defect and one diagnosis does not cover both. coder03 sequenced them together on the shared-form reading; the sequencing still works, the reasoning for it does not. SCOPE: LATENT in both bases. 0 NULL and 0 blank unidad_propulsora cells at the tip snapshot, with the zero controlled by the same predicate returning 1457 / 1874 / 1602 on three columns the book does leave blank. THE DECISION THE ITEM CARRIES IS UNCHANGED AND IS NOT MINE: flag the fabricated blank, which touches stored values, or stop fabricating it, which does not. What the measurement adds is that a third option now exists and is cheaper than both - make the gate's message name the column that is actually empty - and that no data can be lost through this path while the gate stands. NOT EXERCISED: no fix, so nothing seen to pass after one. No import ran. Not measured: whether any other resolver view is keyed on a column whose blank would be misattributed the same way; propulsion is the one instance I seeded.
• db03-mba-l-cc note · 1w ago
  TWO CORRECTIONS CARRIED OVER FROM MOVILBA-749, both measured, neither changes this item's verdict. 1. THE STRICT CATALOG GATE IS MOVILBA-494's, NOT MOVILBA-340's. rutap.vh_norm_reject_unresolved_catalogs was installed on 2026-09-18 by docs/migrations/2026-09-18-movilba-494-guard-catalogos-sin-resolver-DEV-Y-PROD.sql:210, three weeks before 340. I attributed it to 340 in my notes here and in two DMs; the misattribution also travelled into coder03's own note on 749. The severity of this item rests on that gate standing, so the right owner has to be named. 2. 'IT CANNOT CORRUPT DATA WHILE THE GATE STANDS' IS NARROWED. pg_get_triggerdef returns BEFORE INSERT OR UPDATE OF origen, normalizacion_estado, conflictos, and tgattr resolves to exactly those three columns. The eight si/no id columns are NOT in that list, so an UPDATE writing only aire_acondicionado_id and its siblings does NOT fire the gate. The claim holds for the INSERT of a fresh snapshot, which is the path my rehearsal exercises, and NOT for an id-only UPDATE path. rutap.proyectar_snapshot is the only function in rutap or public whose body names normalizar_si_no, but rutap.materializar_snapshot_raices and rutap.reconciliar_snapshot both write rutap.vehiculo_historial_normalizado and are NOT covered by this measurement. ALSO RE-RUN WITH THE RIGHT INPUT: the blank-cell legs had been seeded with the empty string. The importer stores a blank book cell as NULL, never '' - at the tip snapshot of PROD, observaciones is 1457 NULL / 0 empty, expte_baja 1874 / 0, fecha_baja 1602 / 0. Both legs were re-run with NULL in PROD and DEV with identical results, so the verdicts stand, now on the representation the book actually uses. Rehearsal: tools/verification/movilba-751-282-ensayo.sql, sha256 aa7467c6872db8484066870bcd8d9c74169de1c3093af321f0683f498f13d7eb, untracked.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 20:5x ART - MEDICION: la decision que el item pedia se CAE, las dos opciones son una. El item planteaba elegir entre flaguear el blanco que el proyector fabrica (toca el flag) y no fabricarlo (toca el coalesce, o sea valores ya almacenados). Mi medicion anterior habia agregado una tercera cosa: que el mensaje del gate nombre la columna realmente vacia, porque una celda de propulsion en blanco aborta el snapshot diciendo chasis_no_resuelto y nunca menciona la propulsion. Medido, esa tercera cosa NO es una opcion separada: es el efecto de la primera. La cadena, leida del cuerpo instalado y no inferida: el flag de :233 va a conflictos_n, el de chasis de :223 va a pendientes_n, y la columna almacenada conflictos es array_cat(conflictos_n, pendientes_n) (:299). El gate rutap.vh_norm_reject_unresolved_catalogs imprime UNICAMENTE NEW.conflictos - verificado en su cuerpo, position('pendientes') = falso. O sea el mensaje sale de la misma columna que alimentan los dos arrays. Ensayo tools/verification/movilba-751-ensayo-del-predicado.sql, sha256 f3a36e9e, rc=0 en las DOS bases, bajo BEGIN/ROLLBACK, cuerpo instalado ade30cdf intacto despues (re-leido afuera de la transaccion) y las tres sondas del snapshot sintetico 9751 en 0. Tres patas con la MISMA siembra - una celda unidad_propulsora puesta en NULL en la fila_excel 5: A, cuerpo INSTALADO: aborta y el mensaje dice 'chasis_no_resuelto' SOLO. Nunca nombra la propulsion. B, el MISMO cuerpo con el <> '' sacado del predicado de :233: aborta y el mensaje dice 'unidad_propulsora_no_resuelta, chasis_no_resuelto'. CONTROL DE ATRIBUCION: con la celda restaurada, el MISMO snapshot sintetico ENTRA sin abortar y las filas 4, 5 y 6 quedan unidad_propulsora_id 124, estado resuelto, 0 conflictos. El control es lo que hace atribuibles a A y B: sin el, los dos aborts eran compatibles con 'el snapshot 9751 aborta por como se fabrico'. Y ademas establece la causalidad que el item solo suponia: el chasis de esa fila resuelve cuando la propulsion esta, asi que el chasis_no_resuelto de la pata A es CONSECUENCIA del blanco de propulsion. Hoy una celda de propulsion en blanco SI frena el import, y el mensaje nombra la columna equivocada. CONSECUENCIA: sacar el <> '' arregla las dos cosas de una. Y es la opcion que el item describe como la que NO toca valores almacenados. La otra (sacar el coalesce) toca valores ya almacenados y no agrega nada que esta no haga. No queda nada que elegir, asi que no va a Elazar - una opcion que ningun camino mejora no es una decision. ALCANCE HOY, con denominador: 0 celdas de propulsion NULL y 0 en blanco sobre las 5558 filas del snapshot vigente, en las DOS bases (PROD 11, DEV 21). CONTROL del cero, mismo predicado sobre tres columnas que el libro SI deja vacias en ese mismo snapshot: observaciones 1457, expte_baja 1874, fecha_baja 1602. El defecto es LATENTE; lo que se arregla es el silencio y la misatribucion, no un conteo. PRIMERA CORRIDA FALLIDA, anotada porque el sintoma era indistinguible de un hallazgo: el control de atribucion 'restauraba' la celda leyendola de rutap.v_rutap_latest DESPUES de insertar 9751, y como 9751 > el id real la vista devolvia 9751, o sea copiaba NULL sobre NULL. Reportaba un abort que parecia decir que la siembra no era atribuible. El id vigente ahora se congela en una temp antes del INSERT. Tambien: el ancla del replace() llevaba seis comillas en vez de cuatro y dio 0 ocurrencias - lo cazo el assert del propio ensayo. SIN EJERCITAR: no se aplico nada, el apply de 751 sigue secuenciado DESPUES del de MOVILBA-282 porque re-pinnea el mismo cuerpo (nuevo md5(prosrc) esperado a7c701fd). No se midio ninguna superficie de la app, ningun import real, y el ensayo prueba el mensaje del gate - no prueba que el blanco deba o no frenar el import, que es el status quo y no cambia con este arreglo.
• db03-mba-l-cc note · 1w ago
  db03 - correccion de la nota anterior: el '20:5x ART' de su primer renglon es un marcador que quedo sin resolver, no una hora medida. La hora real es la del evento, 2026-10-09T00:04:05.249Z UTC = 21:04 ART del 2026-10-08. Nada mas de esa nota cambia.
• db03-mba-l-cc note · 1w ago
  db03 - RETRACTACION PARCIAL de mi nota de 2026-10-09T00:04:05.249Z. La conclusion 'la decision se cae, las dos opciones son una' es FALSA y la retiro. La decision del item SIGUE EN PIE y ademas cambio de forma. QUE ESTABA MAL, y por que el primer ensayo no lo podia ver. El testigo de movilba-751-ensayo-del-predicado.sql (f3a36e9e) es la fila_excel 5 del libro vigente, que trae chasis_marca y chasis_modelo NO vacios. El flag de chasis de :223 pide justamente que una de esas dos este no vacia, asi que podia disparar - y disparo. O sea en ese testigo el abort lo producia el CHASIS, de rebote, y yo lei 'el blanco de propulsion frena el import hoy'. No se seguia del dato. SEGUNDO ENSAYO, el que separa el rebote del caso: tools/verification/movilba-751-ensayo-chasis-en-blanco.sql, sha256 a0cb8508, rc=0 en las DOS bases, BEGIN/ROLLBACK, cuerpo instalado ade30cdf intacto y re-leido afuera de la transaccion, las tres sondas del snapshot sintetico 9752 en 0. Misma fila, pero con las TRES celdas en NULL - propulsion, chasis_marca y chasis_modelo: PATA A, cuerpo INSTALADO: NO aborta. La fila ENTRA con unidad_propulsora_id NULL, normalizacion_estado 'resuelto' y 0 conflictos. PASA EN SILENCIO. PATA B, el MISMO cuerpo sin el <> '' en :233: ABORTA, y el mensaje dice 'unidad_propulsora_no_resuelta' SOLO, sin el token de chasis. CONTROL DE ATRIBUCION: con las tres celdas restauradas el MISMO 9752 entra sin abortar; filas 4, 5 y 6 con unidad_propulsora_id 124, chasis_id 127/127/130, estado resuelto, 0 conflictos. DENOMINADOR DECLARADO: 0 de 5558 filas del libro vigente vienen sin las dos celdas de chasis, en las dos bases - o sea el testigo esta FABRICADO blanqueando las tres celdas, y eso no es un caso que el libro de hoy traiga. CONTROL del cero, mismo predicado: observaciones vacias 1457 de 5558. LO QUE ESTO CAMBIA. Sacar el <> '' no es 'arreglar que columna nombra el mensaje': convierte un paso SILENCIOSO en un ABORT DURO del snapshot entero. Es un cambio de comportamiento. Y choca con como este mismo proyector trata los otros blancos: MOVILBA-282 deja tramite_id NULL y avisa, MOVILBA-492 deja carroceria_id NULL con el crudo intacto y avisa; ninguno aborta. Tambien choca con el contrato de import fiel - un blanco declarado del libro se importa como esta, y solo un mapeo ausente o ambiguo frena una fila; una celda vacia no tiene mapeo ambiguo, es un blanco. LA DECISION, ahora que esta medida, y NO es la que traia el item. No es flag-vs-coalesce: es que hace el proyector con una celda de propulsion vacia. A) AVISAR: unidad_propulsora_id queda NULL con el crudo intacto y sale un WARNING que nombra la columna y las filas, igual que 282 y 492. No frena ningun import. Es la unica de las dos que no contradice al contrato de import fiel ni a las otras dos decisiones ya tomadas sobre esta misma funcion. B) ABORTAR: sacar el <> '' y que el snapshot entero se rechace nombrando la propulsion. RECOMIENDO A. Lo que el item llamaba 'cambiar el coalesce' no es una opcion aparte: toca valores ya almacenados y no agrega nada que A no haga. Alcance hoy, sin cambio: 0 celdas de propulsion NULL y 0 en blanco sobre las 5558 del snapshot vigente en las dos bases, con el mismo control de 1457/1874/1602 de la nota anterior. El defecto es LATENTE con las dos opciones. LO QUE SIGUE EN PIE de la nota retractada: que conflictos se guarda como array_cat(conflictos_n, pendientes_n) (:299), que el gate imprime unicamente NEW.conflictos, y que con el <> '' sacado el mensaje nombra la propulsion. Lo que NO sigue en pie son los dos renglones que decian que el blanco ya frena el import hoy y que el status quo no cambia. SIN EJERCITAR: no se aplico nada; el apply de 751 sigue secuenciado despues del de MOVILBA-282 y ahora ademas espera la eleccion A/B. Ninguna superficie de la app, ningun import real, y ninguna de las dos patas midio que pasa con mas de una fila en blanco a la vez.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08 21:51 ART. DECISION REBASED on the body MOVILBA-282 installed today - a7c701fd3ac3a18b62e1584b01b102d7, 39723 characters / 39845 octets, identical in both bases. Nothing in the two 751 rehearsal scripts pins a body digest, so they still run as written against the new body: they READ the installed body and derive the variant with replace(), which is why the apply of 282 did not expire them. What the measurement says, and the first version of it was wrong in a way worth keeping visible: the predicate at :233 is CASE WHEN prop_resuelta IS NULL AND prop_n <> '' THEN 'unidad_propulsora_no_resuelta'. My first rehearsal seeded only unidad_propulsora NULL and concluded that the installed body already aborts on a blank propulsion cell, so the item's decision collapsed. That was wrong: the seed row also had non-blank chasis_marca and chasis_modelo, so the chassis flag at :223 could fire and the abort had a second sufficient cause. The decisive rehearsal blanks all three cells on the same row, and then leg A - the installed body - does NOT abort: the row lands with unidad_propulsora_id NULL, normalizacion_estado 'resuelto' and 0 conflictos. SILENTLY. Leg B, with <> '' removed, ABORTS naming unidad_propulsora_no_resuelta alone. So the real choice is not 'does it already work' but WHICH BEHAVIOUR WE WANT, and the two options are not symmetric: removing <> '' converts a silent pass into a hard abort, which contradicts what this project decided twice this week - MOVILBA-282 stores tramite_id NULL and WARNS, MOVILBA-492 stores carroceria_id NULL and WARNS - and contradicts the faithful-import contract, where a stated blank is imported and only an absent or ambiguous mapping blocks a row. OPTIONS FOR ELAZAR, both latent today (0 of 5558 rows in each base have a blank propulsion cell, so neither option changes any current import): A) WARN AND STORE NULL, same shape as 282 and 492 - the row enters, the run names it, nothing is invented. RECOMMENDED. B) ABORT - the import stops until the book or the catalog is fixed. The item's third option, changing the coalesce, is not a separate choice: it touches stored values and adds nothing A does not. NOT EXERCISED: no real import ran under either variant, and leg B's abort has only been seen on a fabricated row, because 0 of 5558 real rows have both chassis cells blank.
• db03-mba-l-cc blocked · 1w ago
  db03 2026-10-09 ART. Measurement complete (full detail in note of 21:51 ART yesterday). Decision for Elazar: when unidad_propulsora is blank on an otherwise-resolvable row, A) WARN and store NULL - same shape as MOVILBA-282 (tramite_id) and MOVILBA-492 (carroceria_id), consistent with the faithful-import contract (RECOMMENDED), or B) ABORT the import until book/catalog is fixed - contradicts both precedents. Both options are latent today: 0 of 5558 rows in either base currently have a blank propulsion cell, so neither changes any live import. No DDL drafted pending the answer.