DEV: 7 app_dev vehiculos ZX000ZX-ZX006ZX saved with no linea and no VDC - census; delete blocked by vh_norm_reject_app_delete

Sub-tickets

Activity

• db03-mba-l-cc created · 3w ago
• db03-mba-l-cc note · 3w ago
  db03-mba-l-cc 2026-09-24 07:48 -03 - DEV census, read-only, nothing deleted. Instrument: psql, current_database=movilba_dev, current_user=movilba_user, 10.9.10.54. Q1 the seven (ids 6788-6794, ZX000ZX-ZX006ZX): origen_ingreso app_dev, creado_por l2eptUQd81rhJSECul6Qe, creado_en 2026-09-23 15:45:11 to 15:50:09, not soft-deleted, chasis_id and carroceria_id NULL. vehiculos has NO linea column; linea and entidad live on rutap.vehiculo_historial_normalizado. Each has exactly 3 history rows, all origen=app, entidad_id 71 (NUEVOS RUMBOS S.A., cuit 30-54657207-9), fecha_alta 2026-09-23; row 1 closed same day, row 2 closed same day (ZX000ZX: row 2 open) - the pattern is 3 rows written within about 1.5 s of the vehiculo insert. estado del ciclo vigente was not read from the ciclo view. vehiculos_datos_colectivos: ZERO rows for all seven (no VDC at all, so no interno, no estado_id, no regimen). Q2 linea: linea_id IS NULL and linea_numero IS NULL at column level on all 21 history rows (no dangling reference: there is no id to resolve). Defect = never had a linea, not a linea pointing at nothing. Q3 audit_log (812 rows, 2025-10-06 to 2026-09-24 07:35): ZERO entries for these seven by record_id, and ZERO rows in the whole window 2026-09-23 15:40-15:56 - the create path for these was not audited, so audit_log cannot say created-without-linea versus emptied-later. What the data does say: all 3 history rows of each dominio were written in the same second window as the vehiculo and all carry NULL linea, and no later row exists - consistent with created without a linea, NOT with a later emptying (an emptying would leave a history row that had one). Not proven by audit. Q4 wider set: 36 app_dev vehiculos in DEV (rest 2396 ssot_import). Those with NO history row carrying a linea: exactly these seven, 0 others; the seven are also the only app rows with 0 VDC. The other 29 all have at least one history row with linea and 1 VDC. Not measured: ssot_import rows lacking a linea, or app rows whose linea was blanked on a later row. Q5 cascade per id (all seven identical): rutap.vehiculo_historial_normalizado 3 (3 origen=app), vehiculos_datos_colectivos 0, vdc_archive 0, validadoras_historial 0, rutap.vdc_mdvr_import_baseline 0, vehiculos_archive 0, audit_log 0. FKs to vehiculos: history (no cascade), vdc, validadoras_historial (RESTRICT), mdvr baseline. Totals: 21 history rows, nothing else. Q6 TRIGGER FIRES. vh_norm_reject_app_delete is BEFORE DELETE on rutap.vehiculo_historial_normalizado and raises integrity_constraint_violation when OLD.origen='app'; all 21 rows are origen=app, and the history rows must go before vehiculos because of the FK. So the delete is NOT reachable without disabling the trigger (DISABLE TRIGGER has no session scope, drops it for every connection in DEV) - needs Elazar's own word. STOP here.
• db03-mba-l-cc note · 3w ago
  db03-mba-l-cc 2026-09-24 07:49 -03 - Addendum, DEV movilba_dev as movilba_user, read-only. 1. creado_en. Vehiculos: ZX000ZX 2026-09-23 15:45:11.43, ZX001ZX 15:45:30.01, ZX002ZX 15:45:44.95, ZX003ZX 15:49:39.24, ZX004ZX 15:49:46.25, ZX005ZX 15:50:01.45, ZX006ZX 15:50:09.44. History rows (ids 286628-286633, 286646-286651, 286664-286666, 286679-286684): each vehiculo's 3 rows land 0.02s, ~0.55s and ~0.57s after its vehiculo insert, same day. ALL 7 vehiculos and ALL 21 history rows are AFTER 2026-09-15 (gate commit 9b734f9a, git time 2026-09-15T06:03-03, v5.5.176). Side of the line: none is before it. Not measured: what version DEV was actually running on 09-23 (the commit date is not the deploy date), and which entry path (form, API, other) created them. So this is not the pre-gate explanation; whether it is a live gate bypass depends on the DEV deploy version. 2. Trigger body (pg_get_functiondef on rutap.vh_norm_reject_app_delete): IF OLD.origen = 'app' THEN RAISE EXCEPTION 'cannot delete app-origin history event %' (integrity_constraint_violation); RETURN OLD. No GUC, no current_setting, no role or session_user test, not SECURITY DEFINER (owner movilba_user); trigger def has no WHEN clause, tgenabled O. Regex over the body for current_setting/current_user/session_user/pg_has_role/set_config: no match. So it was built WITHOUT a sanctioned per-transaction delete path. Stated plainly: no bypass; a delete needs the trigger disabled, or session_replication_role=replica (needs superuser, DEV has none) - neither is a sanctioned path, and DISABLE TRIGGER has no session scope. 3. Interrupted-alta finding, filed separately as MOVILBA-594: 0 VDC rows for these 7 vehiculos with 21 history rows. Census over ALL DEV vehiculos (2432: 36 app_dev + 2396 ssot_import) with at least one history row and no VDC row: exactly 7, all these; 0 among ssot_import and 0 among the other 29 app_dev. So in DEV it is these 7 only, not a standing count of many; whether it recurs is a code question. PROD not measured. Correction accepted: delete scope = these 7 vehiculos + 21 history rows.
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• db03-mba-l-cc note · 2w ago
  db03 2026-10-01: re-checked, state unchanged since the 2026-09-24 census - same 7 rows (ZX000ZX-ZX006ZX), none soft-deleted, same origen_ingreso=app_dev. Delete still blocked: vh_norm_reject_app_delete has no bypass (confirmed in the prior census, no GUC/role test in the trigger body), DISABLE TRIGGER has no session scope in DEV (no superuser), and this remains Elazar's call, not mine to action via hub. No new measurement needed - standing BLOCKED on his explicit word.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01. CIERRO SIN ACCION: la regla permanente ya decide esto y no hace falta una palabra de Elazar para no borrar. Las 7 filas ZX000ZX-ZX006ZX son datos que los usuarios CREARON en DEV. El fallo de Elazar del 2026-09-24, literal, dice que en DEV los datos que los usuarios crearon o editaron no se tocan, y que un colectivo borrado en DEV se desborra. O sea que la ausencia de linea y de VDC no las hace borrables: las hace filas de prueba incompletas, que es exactamente para lo que existe DEV. El trigger vh_norm_reject_app_delete se queda. Quitar un detector de la base pide la misma decision que ponerlo, y aca el detector esta haciendo justo lo que la regla pide. Lo que queda no es un borrado pendiente sino una receta: si alguna vez hace falta rehacer esas filas de prueba, se anota la receta antes de cualquier refresh, porque un import nuevo pisa columnas gobernadas por el libro. Medido por db03-mba-l-cc el 2026-10-01: las mismas 7 filas, ninguna borrada desde el 09-24, el delete sigue sin bypass. Sin cambio de datos ni de DDL.
• coder03-mba-l-cc completed · 2w ago
  completed