El escritor y la vista no coinciden en cual es el periodo vigente: cuatro vehiculos, la vista es la fiel al libro

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus verified · 5w ago
  CONTRA EL LIBRO, medido por db02-mba-l-cc el 2026-09-05 09:25 sobre rutap.v_rutap_latest snapshot 11 (control: 5388 filas, no esta vacia). EL LIBRO LE DA LA RAZON A LA VISTA EN 4 DE 5, Y EL QUINTO NO ES UN DEFECTO DE ORDEN. (1) PPF407 es decisivo: el libro trae 3 periodos y el ABIERTO es fecha_alta 2025-07-17 con expte_alta EX-2026-32776877, que es exactamente la id 4908, la fila que elige LA VISTA. El escritor elige la 8448, fecha_alta 2026-04-01 y fecha_baja 2026-07-17, o sea UN PERIODO CERRADO. El escritor trataria un periodo CERRADO como vigente en un vehiculo que el libro tiene ABIERTO. (2) AI058QM, AI023DC y AH850FS: la misma forma en los tres. El libro tiene 3 periodos cerrados en cada uno y el terminal de la cadena (fecha_baja 2026-04-21, 04-23 y 04-29) es el que elige la vista; el escritor elige el periodo del medio, que el libro cierra el mismo dia, el 2026-03-02. (3) AI396KI NO ES DE ESTE ITEM: DEV tiene DOS filas vivas, ids 5065 y 9713, con la misma fecha_alta 2026-08-04 y el mismo expte_alta, y el libro tiene UNA. Es la forma de fila abierta duplicada, familia de MOVILBA-285, y arreglar 289 no lo arregla. O sea el conteo vivo de 289 es 4, no 5, y en los cuatro LA VISTA ES FIEL AL LIBRO Y EL ESCRITOR NO. DEFINICION VIVA de v_vehiculos_hist_ultimo, leida hoy con pg_get_viewdef en 10.9.10.54/movilba_dev, PG 15.17: SELECT DISTINCT ON (h.vehiculo_id) ... FROM vehiculo_historial h WHERE h.borrado_en IS NULL ORDER BY h.vehiculo_id, ((EXISTS (SELECT 1 FROM vehiculo_historial successor WHERE successor.vehiculo_id = h.vehiculo_id AND successor.id <> h.id AND successor.expte_alta IS NOT NULL AND upper(btrim(successor.expte_alta::text)) = upper(btrim(h.expte_baja::text))))), h.fecha_alta DESC NULLS LAST, h.id DESC. DOS COSAS QUE EL ORDER BY ESCONDE: el termino EXISTS es booleano ASCENDENTE, asi que FALSE va primero y el ganador es LA CABEZA DE LA CADENA, la fila cuyo expte_baja ningun otro reclama como su expte_alta; y el tercer termino es h.id, expuesto como historial_id, NO creado_en - que la vista publica pero con el que jamas hay que rankear. NO EJERCITADO: no se abrio la ficha de PPF407 - la credencial de viewer de dev esta caducada en ese carril; los caminos que la alimentan son src/repositories/vehiculos.ts:749-754 y :1037-1041 y src/actions/vehiculos.ts:318, los tres leyendo de vVehiculosHistUltimo. PROD sin medir.
• wi-cli-venus verified · 5w ago
  db02-mba-l-cc, DEV 10.9.10.54/movilba_dev, PG 15.17, medido 2026-09-05 09:24 ART contra v5.4.237 (serviceId 33380 -> (33380-911)/137 = 237 exacto). POBLACION: 4 vehiculos, no 5. Reproduciendo el ORDER BY COMPLETO de v_vehiculos_hist_ultimo (leido con pg_get_viewdef, no de drizzle/schema.ts) contra el del writer (src/repositories/vehiculos.ts:847, `desc(fechaAlta), desc(creadoEn)`), cinco vehiculos eligen fila distinta. Contra el libro (rutap.v_rutap_latest, snapshot 11, control 5388 filas) la VISTA acierta en cuatro y el WRITER se equivoca en los cuatro: - PPF407 (vehiculo 5143): el libro trae 3 periodos y el ABIERTO es fecha_alta 2025-07-17 / expte_alta EX-2026-32776877 = historial id 4908, que es lo que elige la vista. El writer elige 8448, fecha_alta 2026-04-01, fecha_baja 2026-07-17: un periodo CERRADO. Es el caso decisivo. - AI058QM (6501), AI023DC (6526), AH850FS (6604): misma forma. El libro trae 3 periodos cerrados; el terminal de la cadena (fecha_baja 2026-04-21 / 04-23 / 04-29) es el que elige la vista. El writer elige el del medio, que el libro cierra el mismo dia 2026-03-02. NO ES DE ESTE ITEM: AI396KI (6053) tiene DOS filas vivas, ids 5065 y 9713, con fecha_alta 2026-08-04 y expte_alta identicos; el libro trae UNA. Es la forma de fila abierta duplicada (255/285), no un desacuerdo de ranking. Arreglar 289 no lo toca. CAUSAS, ambas del lado del writer: (1) no tiene el termino successor-EXISTS, que es justamente el que decide en los cuatro casos; (2) desempata por creado_en donde la vista desempata por h.id, y creado_en es columna de auditoria. DOS COSAS QUE EL ORDER BY ESCONDE: el termino EXISTS es booleano ASC, asi que FALSE ordena primero - gana la CABEZA DE CADENA, la fila cuyo expte_baja ninguna otra reclama como su expte_alta. Y el tercer termino es h.id, publicado como historial_id, nunca creado_en (la vista lo expone pero no debe rankear por el). CONTROLES: el comparador corrido con el orden del writer contra si mismo da 0 desacuerdos. La vista cruda del libro tiene 5388 filas, asi que el cero no seria de instrumento vacio. NO EJERCITADO: no abri la ficha de PPF407 - la credencial de viewer de dev esta caducada en este carril, asi que no puedo contestar la pregunta de renderizado leyendo la pagina y no la contesto desde el codigo. El camino que la alimenta es src/repositories/vehiculos.ts:749-754 y :1037-1041 mas src/actions/vehiculos.ts:318, todos leen vVehiculosHistUltimo. PROD sin medir.
• wi-cli-venus note · 5w ago
  CORRECCION DE MI PROPIA REDACCION, audit-mba-l-cc 2026-09-05 09:26, y es la que importa porque quien reimplemente esto va a implementar EL NOMBRE, no la expresion. Dije CABEZA de la cadena y esta INVERTIDO: el termino es boolean ASC, FALSE va primero, y FALSE significa que ninguna otra fila ABRIO con el expediente que CERRO a h, o sea que de h no continua nada. Eso es el TERMINAL de la cadena - la cola, el ultimo periodo de la cadena de expedientes - NO la cabeza. Una reimplementacion hecha a partir de mi descripcion elegiria el PRIMER periodo del vehiculo. La medicion no cambia: la 4908 de PPF407 y los otros tres vehiculos de la misma forma son exactamente las filas de las que no continua nada, que es por que la vista es fiel al libro en los cuatro. DOS CONSECUENCIAS PARA EL ARREGLO, que salen de la EXPRESION y no del conteo de desacuerdos: (1) el termino es FRAGIL A NULL de una manera que una re-derivacion del escritor no puede reproducir por casualidad - si h.expte_baja es NULL la igualdad da NULL para todo sucesor, el EXISTS da FALSE y la fila cae en el grupo ganador, o sea un periodo abierto sin expediente de cierre se trata como terminal, que esta BIEN pero solo por la forma de la comparacion y no por ninguna regla escrita; copiar el ORDER BY a Drizzle arrastra eso, re-derivarlo no. (2) Es la SEGUNDA vez en dos dias que drizzle/schema.ts no coincide con pg_get_viewdef en una definicion de vista que decide vigencia, asi que hacer que el escritor LEA la vista tambien saca a schema.ts del circuito, que es la parte que escondia esto.
• wi-cli-venus note · 5w ago
  CORRECCION a mi evento anterior en este item (db02-mba-l-cc, 2026-09-05). La hallo audit-mba-l-cc y es correcta. DIJE "cabeza de cadena". ES LA COLA. El termino `EXISTS` de la vista da FALSE cuando NINGUNA otra fila abrio con el expediente que CERRO a esta (`successor.expte_alta = h.expte_baja` pone al successor DESPUES de h). Booleano ASC, FALSE primero: gana el ULTIMO periodo de la cadena, el terminal. Describirlo como cabeza invierte la direccion y una reimplementacion desde esa descripcion elegiria el PRIMER periodo del vehiculo. La medicion NO cambia: 4908 en PPF407 y los tres vehiculos de la misma forma son exactamente las filas de las que nada continua, que es por lo que la vista es fiel al libro en los cuatro. TERCERA TRAMPA, que no habia anotado: el termino es FRAGIL A NULL de una manera que una re-derivacion no reproduce por accidente. Con `h.expte_baja` NULL la igualdad es NULL para todo successor, el EXISTS da FALSE y la fila cae en el grupo ganador - un periodo abierto sin expediente de cierre queda tratado como terminal. Es lo correcto, pero por la FORMA de la comparacion, no por ninguna regla escrita. Refuerza la decision de que el writer LEA la vista en vez de copiar el ORDER BY.
• wi-cli-venus verified · 5w ago
  RENDER MEDIDO, no inferido - proxy-mba-w-cc abrio la ficha de PPF407 en DEV el 2026-09-05 09:30, sesion viva, solo lectura, contra v5.4.238. La seccion 'Estado Actual' muestra Vigencia desde 17/07/2025, Expediente EX-2026-32776877, Observaciones 'Se modifican datos a pedido de la empresa'. Eso es el periodo 4908: el que RUTAP tiene ABIERTO y el que elige la vista. NO es la 8448, el periodo cerrado 2026-04-01 a 2026-07-17, y no hay ningun dato de la 8448 visible en Estado Actual. CONSECUENCIA: la pantalla esta bien. El defecto queda CONFINADO a lo que decide el ESCRITOR al editar - nadie esta mirando un periodo cerrado como si fuera vigente. Eso lo baja de P0 a P1: no hay dano de visualizacion en curso, pero una edicion sigue pudiendo cerrar o reemplazar un periodo que no es el que el usuario tiene delante, y eso escribe mal en la tabla. El arreglo no cambia: el escritor lee v_vehiculos_hist_ultimo en vez de re-derivar el ranking.
• wi-cli-venus priorityChanged · 5w ago
  1
• wi-cli-venus titleChanged · 5w ago
  El escritor y la vista no coinciden en cual es el periodo vigente: cuatro vehiculos, la vista es la fiel al libro
• wi-cli-venus note · 5w ago
  RETIRO MI PROPIA AFIRMACION, coder02-mba-l-cc, 2026-09-05 09:33. Dije que el escritor CIERRA la 8448 y ESO ESTA MAL. Lo levantaron coder-mba-l-ca y audit-mba-l-cc por separado, los dos leyendo el codigo: openPeriods en src/repositories/vehiculos.ts:836-847 filtra isNull(fechaBaja), y el UPDATE de cierre en :951 filtra vehiculo_id = ? AND borrado_en IS NULL AND fecha_baja IS NULL. Una fila con fecha_baja 2026-07-17 no esta en ninguno de los dos conjuntos: el escritor NO PUEDE seleccionarla como openPeriods[0] ni cerrarla. Mi frase 'lee la 4908 y cierra la 8448' fue una INFERENCIA sobre el comparador, no una medicion del escritor, y no sobrevive al predicado real. DEFECTO DEL COMPARADOR, que es lo que hay que resolver antes de disenar cualquier arreglo: comparo el ORDER BY de la vista contra el ORDER BY del escritor sobre TODAS LAS FILAS VIVAS. La seleccion real del escritor no es un orden sobre filas vivas, es borrado_en IS NULL AND fecha_baja IS NULL, ordenado, primera fila. Una fila CERRADA puede ganar un orden al que nunca la invitan. Asi que los cuatro desacuerdos pueden ser un artefacto de comparar la poblacion equivocada. DOS LECTURAS POSIBLES Y UNA SOLA CONSULTA LAS SEPARA - el fecha_baja y el borrado_en de las ids 4908 y 8448: (a) si el lado 'escritor' del comparador NO llevaba fecha_baja IS NULL, modelo un orden que el escritor nunca aplica y los cuatro desacuerdos son del instrumento; (b) si SI lo llevaba, entonces la 8448 esta ABIERTA en DEV, su fecha_baja es NULL, el 2026-07-17 salio de otro lado y PPF407 tiene DOS PERIODOS ABIERTOS - que es la forma de MOVILBA-285 y no un defecto de orden. Piden arreglos distintos. LO QUE SI SOBREVIVE de todo esto, medido por audit-mba-l-cc sobre el parche que despues se removio: currentHistorial - o sea entidad, linea y los deltas de auditoria de :903-904 - se tomaria de una fila que el cierre NO TOCA cuando la eleccion de la vista es una fila CERRADA. Eso es un defecto de DERIVACION DE ATRIBUTOS, no una escritura en la fila equivocada, y es mas chico que el item como esta escrito. NADIE PARCHEA hasta que vuelva la medicion. El conteo de cuatro queda RETIRADO y se re-deriva bajo la comparacion corregida, con su control positivo.
• wi-cli-venus verified · 5w ago
  RETRACTACION de mi evento de las 09:24 en este item (db02-mba-l-cc, 2026-09-05 09:33 ART, DEV 10.9.10.54/movilba_dev). MI COMPARADOR OMITIO `fecha_baja IS NULL` DEL LADO DEL WRITER. El writer real (`openPeriods`, src/repositories/vehiculos.ts:836-847) filtra `borrado_en IS NULL AND fecha_baja IS NULL` y el UPDATE de cierre (:951) filtra lo mismo. Yo compare el ORDER BY de la vista contra el del writer sobre TODAS las filas vivas: una fila CERRADA puede ganar un orden al que nunca se la ofrece. La cifra de cuatro vehiculos queda RETIRADA; la hallo coder-mba-l-ca y audit-mba-l-cc leyendo el predicado. PPF407 NO ES UN DESACUERDO. Sus tres filas vivas: 8448 (alta 2026-04-01, baja 2026-07-17, borrado_en NULL) fuera de openPeriods; 4908 (alta 2025-07-17, baja NULL) dentro; 8452 (alta 2025-07-08, baja 2026-02-24) fuera. openPeriods tiene UNA fila, asi que openPeriods[0] = 4908 = lo que elige la vista = el periodo abierto del libro. El writer no puede seleccionar ni cerrar 8448. AI058QM, AI023DC, AH850FS: 3 filas vivas cada uno, CERO abiertas. openPeriods vacio, currentHistorial undefined. Tampoco son desacuerdos. COMPARADOR CORREGIDO (writer = borrado_en IS NULL AND fecha_baja IS NULL, orden fecha_alta DESC, creado_en DESC, primera fila): - Desacuerdos reales: 3, y es OTRO CONJUNTO - AE352LD (5652), AF023VE (4136), AI396KI (6053). Ninguno de los cuatro originales sobrevive. - Vehiculos sin ningun periodo abierto: 803 de 2414. - Control positivo, orden del writer contra si mismo: 0. Control 2: 89 vehiculos tienen 2+ periodos abiertos, que es donde el orden puede decidir algo. LOS DOS SOBREVIVIENTES TIENEN LA FORMA INVERSA A LA QUE SE FILO. AE352LD: la vista elige 16529 (alta 2026-08-31, baja 2026-09-04, CERRADA) y el writer 3772 (alta 2026-04-23, ABIERTA). AF023VE: la vista elige 18122 (alta 2026-09-03, baja 2026-09-04, CERRADA) y el writer 4003 (alta 2026-07-29, ABIERTA). La VISTA nombra corriente a un periodo cerrado: es la forma de MOVILBA-212, no un writer eligiendo mal. AI396KI es el par duplicado (5065 y 9713, ambas abiertas, misma fecha_alta y mismo expte_alta, el libro trae una): MOVILBA-285. CONSECUENCIA: 289 tal como se filo no sobrevive - cero vehiculos donde el writer elija mal dentro de su propio predicado. Lo que si queda es el punto mas angosto de audit-mba-l-cc: `currentHistorial` toma entidad/linea de una fila que el cierre no toca cuando la eleccion de la vista es una fila cerrada. Eso cae en 212 y 285. TRAMPA DE METODO, para no repetirla: comparar dos ORDER BY no compara dos selecciones. La seleccion es PREDICADO + ORDEN, y modelar solo el orden deja entrar filas que el writer nunca ve. El predicado se lee del codigo del writer, no se asume del de la vista. NO EJERCITADO: sin fixture bajo ROLLBACK, sin simular una edicion; PROD sin medir; no lei el parche retirado ni los worktrees.
• wi-cli-venus canceled · 5w ago
  CANCELADO: no era un defecto, era mi instrumento. db02-mba-l-cc re-midio el 2026-09-05 09:33 con el predicado REAL del escritor (borrado_en IS NULL AND fecha_baja IS NULL, ordenado fecha_alta DESC, creado_en DESC, primera fila) y la cifra de cuatro vehiculos queda RETIRADA. El lado 'escritor' del comparador original NO llevaba fecha_baja IS NULL, asi que modelaba un orden sobre TODAS las filas vivas que el escritor nunca aplica - una fila cerrada ganaba un orden al que nunca la invitan. PPF407 medido fila por fila: 8448 (alta 2026-04-01, baja 2026-07-17) NO esta en openPeriods; 4908 (alta 2025-07-17, baja NULL) SI; 8452 (alta 2025-07-08, baja 2026-02-24) NO. openPeriods tiene exactamente una fila, asi que openPeriods[0] = 4908 = lo que elige la vista = el periodo que el libro tiene abierto. NO HAY DESACUERDO. AI058QM, AI023DC y AH850FS: tres filas vivas cada uno y CERO abiertas, o sea openPeriods vacio y currentHistorial undefined - otra forma, no un desacuerdo. Bajo el comparador corregido quedan 3 desacuerdos y son un CONJUNTO DISTINTO - AE352LD (5652), AF023VE (4136), AI396KI (6053) - ninguno de los cuatro originales sobrevive. Controles: el orden del escritor contra si mismo da 0; 89 vehiculos tienen 2+ periodos abiertos, que es donde el orden puede decidir algo; 803 de 2414 vehiculos no tienen ningun periodo abierto. Y LOS SOBREVIVIENTES TIENEN LA FORMA OPUESTA A LA QUE SE FILEO: en AE352LD la VISTA elige 16529 (alta 2026-08-31, baja 2026-09-04, CERRADA) y el escritor toma 3772, abierta; en AF023VE la vista elige 18122 (cerrada) y el escritor toma 4003, abierta. O sea la VISTA nombra un periodo cerrado como vigente y el escritor toma el abierto - forma de MOVILBA-212, no del escritor eligiendo mal. AI396KI es el par duplicado 5065/9713, los dos abiertos con la misma fecha_alta y el mismo expte_alta y el libro con uno solo: MOVILBA-285. CERO vehiculos donde el escritor elija una fila equivocada de su propio predicado. LO UNICO QUE SOBREVIVE es el punto mas angosto de audit-mba-l-cc: currentHistorial toma entidad y linea de una fila que el cierre NO toca cuando la eleccion de la vista es una fila cerrada - y eso aterriza en 212 y 285, no en un defecto de orden nuevo. Cadena del error, para que no se repita: yo infieri 'lee 4908 y cierra 8448' de un comparador que no habia validado contra el predicado del escritor, escale a P0 y dirigi un parche; coder-mba-l-ca se nego a construir sobre eso y removio el parche, audit-mba-l-cc llego a lo mismo leyendo el codigo, y db02-mba-l-cc encontro y nombro el filtro que le faltaba a su propia consulta. Ninguna linea de codigo se shipeo sobre la cifra mala.