El expediente se guarda verbatim en vehiculo_historial y trimmeado+truncado a 110 en validadoras_historial para el mismo tramite
Encontrado por audit-mba-l-ca el 2026-09-24 auditando el ship de MOVILBA-362 (81ba703c, v5.6.46), y verificado en el arbol por coder03-mba-l-cc. MOVILBA-362 preserva el texto crudo del expediente en el camino de modificacion de colectivo y en todas las escrituras a vehiculo_historial; validadoras_historial queda afuera y sigue guardando un valor alterado. CAMINO: cuando la misma edicion de colectivo cambia el dominio, o produce una BAJA, y eso desvincula validadoras EMBARCADAS, services/vehiculos.ts:931 pasa el expediente crudo a desvincularEmbarcadasDelVehiculo. services/validadoras-vehiculo.ts:123-128 (expedienteDelEvento) hace params.expediente?.trim() y despues .slice(0, 110). requiredText de validadoras.ts vuelve a trimmear, y repositories/validadoras.ts escribe ese valor a public.validadoras_historial.expediente. O sea que el mismo expediente queda verbatim en vehiculo_historial y normalizado en validadoras_historial para el MISMO tramite. POR QUE ES UNA DECISION Y NO UN ARREGLO OBVIO, que es lo que hay que resolver primero: el comentario in-code de validadoras-vehiculo.ts:120-122 dice que esa columna tiene CHECK expediente_no_vacio y que el valor es una CADENA DE FALLBACK - expediente, si no motivoTramite, si no una descripcion del hecho. O sea que el campo no es el expediente del libro sin mas, es el identificador del evento de la validadora, y ahi normalizar puede ser el diseno. Lo que NO se puede defender igual de facil es el truncado a 110: es lossy y silencioso. La columna tiene contrato de 110 caracteres, asi que preservar el crudo pide decidir que pasa cuando el expediente del libro no entra - truncar, ensanchar la columna, o aceptar la divergencia y documentarla. QUE HAY QUE MEDIR ANTES DE DECIDIR: cuantas filas de validadoras_historial en DEV y en PROD tienen expediente de exactamente 110 caracteres (candidatas a truncado real) y cuantas difieren del expediente de la fila de vehiculo_historial del mismo tramite. Si son cero en las dos bases, la decision es barata y documental; si no, es un arreglo de datos ademas de un arreglo de codigo. Ojo que un cero solo discrimina si la poblacion que lo haria distinto de cero existe - decir cuantos tramites de este tipo hay en total. NO EJERCITADO Y ES PARTE DEL HALLAZGO: tools/tests/colectivo-expediente.test.cjs fuerza estadoAntes=null, asi que la rama condicional que desvincula validadoras no se ejecuta nunca en el test. El gate de MOVILBA-362 no cubre este camino y no se lee como si lo cubriera.
Activity
-
parent=#3515
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db03-mba-l-cc / db
-
MEASURED db03 2026-10-09: population of this bug's actual trigger (automatic desvinculacion, nota marker '(MOVILBA-266)') is 0/0 on PROD and DEV. PROD: public.validadoras_historial has 0 rows total (feature unexercised, consistent with validadoras being hidden/not-live). DEV: 59 rows, all manual/mock seed data (tools/validadoras-seed-dev.ts, observaciones literally say 'Mock...No migrar a PROD'), 0 of them carry the MOVILBA-266 marker - the auto-desvinculacion code path has never actually run on either base. Broader check regardless of marker: DEV expediente length distribution is {30,28,26,14,12,11,3} chars, 0 rows at exactly 110 (the truncation-candidate length). Positive control: total-row and evento_tipo_id group-by queries return real nonzero counts (59, grouped 323/324/327), so the 0-match queries are true zeros, not a broken probe. Per the ticket's own framing: population is cero in both bases -> decision is cheap and documental, not a data-fix. Code confirmed unchanged since the finding (services/validadoras-vehiculo.ts expedienteDelEvento: trim->slice(0,110), CHECK expediente_no_vacio comment intact) and services/vehiculos.ts writes expediente verbatim (no trim/slice) to rutap.vehiculo_historial_normalizado.expte_alta/expte_baja (text, no length cap) at the same call site. Remaining open piece is the design decision (truncate vs widen column vs document) plus the test-gate finding (colectivo-expediente.test.cjs forces estadoAntes=null, never exercises the desvinculacion branch) - both still need Elazar/coder03, routing.
-
Decide: A) keep slice(0,110) as documented lossy behavior (column stays 110, divergence from vehiculo_historial's verbatim text is accepted+documented) B) widen validadoras_historial.expediente past 110 (removes the lossiness, needs a column-width migration) C) leave as-is, no doc change (not recommended - comment at validadoras-vehiculo.ts:120-122 already explains the fallback-chain design, but the 110 truncation itself is undocumented as lossy). Measured population is 0/0 both bases (see note) so this is purely a design call, not a data-fix - cheap either way. Separately (coder-lane, not blocked): tools/tests/colectivo-expediente.test.cjs forces estadoAntes=null and never exercises the desvinculacion branch - gate doesn't cover this path.