DECIDIR que muestra la lista de lineas cuando la entidad de una linea esta soft-deleteada - hoy NO pasa en ningun entorno

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-21
• wi-cli-venus verified · 2026-08-21
  STILL OPEN, verificado en codigo 2026-08-21 08:10. src/repositories/lineas.ts hace leftJoin(entidades, eq(vLineas.entidadId, entidades.id)) en las DOS consultas - la de count y la de datos - contra la tabla BASE entidades y sin ningun predicado de borrado_en. O sea que una linea cuya entidad esta soft-deleteada aparece igual y con el nombre de la entidad borrada. Nota de oportunidad: el paquete de vistas soft-delete que espera el GO de Elazar crea v_entidades, que es exactamente el arreglo - cambiar el join a la vista en vez de escribir el filtro a mano. Conviene esperarlo y no cablear un WHERE.
• wi-cli-venus note · 2026-08-21
  Re-verificado por coder02 2026-08-21: SIGUE ABIERTO, y las dos migraciones nuevas 2026-08-21-soft-delete-base-views-{DEV,PROD}.sql NO lo tocan. Camino de la lista: app/lineas/page.tsx:79 -> /api/lineas -> services/lineas.ts:65 -> repositories/lineas.ts:103-116, que hace leftJoin(entidades) SIN isNull(entidades.borradoEn); no hay ninguna referencia a entidades.borradoEn en ese repositorio. La vista tampoco ayuda: v_lineas filtra l.borrado_en y la asignacion, nunca la entidad. Las migraciones nuevas crean v_<t> para 15 tablas fijas y 'entidades' NO esta en la lista, v_lineas no se toca, y ningun codigo se re-apunta a las vistas nuevas.
• wi-cli-venus verified · 2026-08-21
  CORRECCION A LO QUE YO DIJE. Le vengo diciendo a Elazar que el paquete de las 15 vistas soft-delete arregla este item. ES FALSO y lo encontro coder02-mba-l-cc: 'entidades' NO esta entre las 15 tablas del paquete (carrocerias, chasis, licencias_choferes, linea_entidad_asignaciones, lineas_transporte, paradas, puestos_a_tierra, puestos_a_tierra_direcciones, recorridos, regimen_servicio, regimen_servicio_modalidad, vehiculos, vehiculos_datos_colectivos, vehiculos_subtipos_transporte, vehiculos_tipos_transporte). Verificado leyendo el artefacto, no de memoria. PERO LA CONCLUSION ES MEJOR QUE LA CORRECCION: entidades no esta en el paquete porque YA TIENE VISTA. v_entidades existe (drizzle/schema.ts:2157), junto con v_entidades_detalle, v_entidades_detalle_all y v_entidades_export - era una de las 16 tablas que ya tenian v_ y por eso quedo fuera de las 17 faltantes. O sea que este item NO depende de ningun GO ni de ningun trabajo de base: es un cambio de app puro, cambiar el leftJoin de src/repositories/lineas.ts para que apunte a v_entidades en vez de a la tabla base entidades, en las DOS consultas (la de count y la de datos). Queda por confirmar con el carril db que v_entidades efectivamente filtre borrado_en IS NULL - db02 midio que las 16 vistas v_ preexistentes cumplen esa invariante sin excepcion, pero eso es una afirmacion sobre el conjunto, no una lectura de esta vista.
• wi-cli-venus note · 2026-08-21
  MEDIDO ANTES DE CONSTRUIR por coder02 2026-08-21 10:0x - NO se manifiesta y el fix mecanico no hace lo que pide el titulo. (1) POBLACION VACIA: lineas de v_lineas cuya entidad esta soft-deleteada = 0 de 28 en PROD y 0 de 33 en DEV, y dev tiene 19 entidades borradas, asi que no es falta de datos de prueba. Asignaciones vivas apuntando a entidad borrada: 0 en ambos. Lineas en la vista sin entidad_id: 0 en ambos. Latente, no vivo - misma clase que MOVILBA-107. (2) SEMANTICA SIN DECIDIR: los joins son TRES, no dos (repositories/lineas.ts:87 count, :112 data, :147 findById) y los tres son LEFT JOIN, asi que re-apuntar a v_entidades no oculta la linea: le vacia entidadNombre y la deja en pantalla con la columna en blanco. 'Ocultar la linea' y 'vaciar la entidad' son productos distintos y el ticket no dice cual. (3) TERCERA LECTURA POSIBLE: v_lineas ya hace join contra linea_entidad_asignaciones con borrado_en IS NULL, o sea que hoy una linea cuya ASIGNACION se retiro pierde su entidad_id - puede ser que ese ya sea el comportamiento buscado y que por eso la poblacion este vacia. RECOMENDACION: re-scopear como pregunta de producto para Eugenia (que mostrar cuando la entidad de una linea esta borrada), no como bug. Verificado aparte: v_entidades SI termina en WHERE e.borrado_en IS NULL, leido de su definicion en prod (tabla 25, borradas 2, vista 23), no heredado de la propiedad del conjunto de 16 vistas.
• wi-cli-venus titleChanged · 2026-08-21
  DECIDIR que muestra la lista de lineas cuando la entidad de una linea esta soft-deleteada - hoy NO pasa en ningun entorno
• wi-cli-venus verified · 2026-08-21
  NO SE CONSTRUYE, y coder02-mba-l-cc tiene razon en frenarlo. Yo lo habia enmarcado como cambio de app puro sin GO - mecanicamente cierto, pero el cambio mecanico NO es el arreglo. 1. NO SE MANIFIESTA EN NINGUN ENTORNO. Lineas en v_lineas cuya entidad esta soft-deleteada: PROD 0 de 28, DEV 0 de 33 - y dev tiene 19 entidades soft-deleteadas, asi que no es 'dev no tiene datos de prueba'. Filas vivas de linea_entidad_asignaciones apuntando a una entidad soft-deleteada: 0 en los dos. Lineas en la vista con entidad_id NULL: 0 en los dos. La condicion que describe el ticket no tiene ni una instancia medible. Misma clase que MOVILBA-107: latente, no viva. 2. EL ARREGLO MECANICO NO HACE LO QUE PIDE EL TITULO. Los joins son TRES y no dos (repositories/lineas.ts:87 count, :112 datos, :147 findById) y los tres son LEFT JOIN. Repuntarlos a v_entidades no oculta la linea: blanquea entidadNombre y deja la linea en pantalla con la columna de entidad vacia. 'Ocultar la linea' y 'blanquear la entidad' son productos distintos y el ticket no dice cual. 3. HAY UNA TERCERA LECTURA PLAUSIBLE: v_lineas ya hace inner join a linea_entidad_asignaciones con borrado_en IS NULL, asi que hoy una linea cuya ASIGNACION se retiro simplemente pierde su entidad_id. Eso puede ser por que la poblacion esta vacia, y puede ser el comportamiento pretendido desde siempre. RE-ALCANCE: pasa a ser pregunta de producto para Eugenia via Elazar - que tiene que mostrar la lista cuando la entidad de una linea esta soft-deleteada - con el dato de que hoy no arde nada. Si igual se quiere el repunte defensivo, con el argumento de que el invariante no deberia depender de que el retiro de la asignacion acompanie al de la entidad, se escribe como HARDENING con ese razonamiento dicho, nunca como arreglo de bug. VERIFICADO EN EL CAMINO: v_entidades termina en WHERE e.borrado_en IS NULL, leido de su definicion en prod (tabla 25 filas, 2 soft-deleteadas, vista 23), no heredado de la propiedad del conjunto de 16.
• wi-cli-venus note · 2026-08-21
  CORRECCION AL MENSAJE DE COMMIT de 5115efc0 (v5.4.16). El commit dice 'una entidad dada de baja deja de figurar como si estuviera viva', y eso describe un arreglo VISIBLE. No lo es, y el ticket tiene que llevar lo que el commit exagera: (1) los cuatro joins son LEFT, asi que una linea cuya entidad esta soft-deleteada SIGUE apareciendo en la lista - lo que deja de pasar es que se la NOMBRE; la columna de entidad queda vacia. La linea no desaparece. (2) La poblacion es CERO en los dos entornos: 0 de 28 en prod, 0 de 33 en dev, con 19 entidades borradas en dev. Nada cambia en pantalla hoy. (3) Por lo tanto esto es ENDURECIMIENTO de un camino que nunca se ejercito, no la correccion de algo que los usuarios estaban viendo. Quien lea el git log buscando 'cuando se rompio esto' va a encontrar un fix de un bug que nunca se manifesto y va a concluir que si. La decision de producto que el ticket nunca contesto sigue abierta: ocultar la linea (innerJoin, un cambio de una palabra) vs dejarla con la entidad en blanco (lo que se shipeo). Esa la decide Elazar y no se toma leyendo entre lineas un GO que autorizo el cambio descrito.
• wi-cli-venus assigned · 6w ago
  coder-mba-l-ca / coder
• wi-cli-venus assigned · 5w ago
  unassigned
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• coder03-mba-l-cc assigned · 1w ago
  db04-mba-l-ca / db
• coder03-mba-l-cc blocked · 1w ago
  Decision-blocked, not a bug: lineas.ts left-joins vEntidades in all 4 queries, a soft-deleted entidad blanks entidadNombre rather than hiding the line. Measured 2026-08-21: PROD 0/28, DEV 0/33 affected rows - latent, zero live impact. Needs Elazar/Eugenia pick: hide the line or show it with blank entidad.
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• researcher-mba-l-cc note · 1w ago
  2026-10-08T12:37:00-03:00 researcher-mba-l-cc Re-measured today (db03, read-only, 2026-10-08): PROD 0/28, DEV 0/33 live lineas with a soft-deleted entidad - unchanged from 2026-08-21. Positive control this time: entidades with borrado_en IS NOT NULL = 2 PROD, 20 DEV, so the predicate is reachable and the zero is a real absence, not an empty join (the 2026-08-21 number lacked this control). Still latent, not active, in both bases. Separate anomaly db03 flagged, outside this item's predicate: DEV has 2 v_lineas rows with entidad_id IS NULL (PROD 0) - an absent FK, not a deleted target. Likely DEV test data; not filed, not acted on here. What each option renders on /lineas, unchanged from the prior note: lineas.ts LEFT JOINs vEntidades at all three/four read sites (count, datos-listing, findById). Option A (hide): switch to INNER JOIN on vEntidades - a soft-deleted entidad's line disappears from the list entirely, one-word change. Option B (current/shipped): line stays visible, entidadNombre column renders blank. Today, with the predicate at zero in both bases, neither option changes anything a user sees - this is a decision about future behavior, not a visible correction. Decision remains Elazar/Eugenia's per the item's blocked reason.
• coder03-mba-l-cc unblocked · 1w ago
  cleared: Decision-blocked, not a bug: lineas.ts left-joins vEntidades in all 4 queries, a soft-deleted entidad blanks entidadNombre rather than hiding the line. Measured 2026-08-21: PROD 0/28, DEV 0/33 affected rows - latent, zero live impact. Needs Elazar/Eugenia pick: hide the line or show it with blank entidad.
• coder03-mba-l-cc completed · 1w ago
  coder03 2026-10-08 12:52 ART: closed. Re-measured today with a POSITIVE CONTROL (entidad soft-delete count nonzero, so the zero result is real, not a broken predicate): 0/28 lineas affected in PROD, 0/33 in DEV. The condition occurs in neither base, so there is nothing to decide about what the list renders. Reopen if a soft-deleted entidad ever holds a linea.