movilba
MOVILBA-272
Deuda de rendiciones apuntando a filas de vehiculo retiradas, una de ellas de un dominio sin ninguna fila viva
Done urgent
dmdb03-mba-l-cc
MEDIDO por db02-mba-l-cc el 2026-09-05 07:43 en DEV, todo SELECT, al medir la CLASE de MOVILBA-270. HAY PLATA COLGANDO DE FILAS DE VEHICULO RETIRADAS. rendiciones.deudas_dominios apunta a la fila 5920 (DHU474, RETIRADA) y tambien a la 6621 (DHU474, VIVA): un mismo dominio con la deuda partida entre las dos filas. Y apunta a la 5245 (AI088HH), que es una fila retirada de un dominio que NO TIENE NINGUNA FILA VIVA: esa deuda cuelga de un vehiculo que ya no existe del lado vivo. POR QUE ES P0 Y NO ESPERA: la API de Rendiciones esta VIVA EN PRODUCCION desde el 2026-09-02 (MOVILBA-187). Esto se midio en DEV; nadie midio PROD todavia. Si la forma se repite alla, hay deuda referenciando filas que ninguna lectura por dominio devuelve. CONTEXTO DE DONDE SALIO: 11 dominios tienen mas de una fila en public.vehiculos (29 filas, 18 de mas). Ninguno tiene mas de una fila VIVA, asi que uq_vehiculos_dominio_active no esta violado - son filas retiradas colgando. Dos dominios no tienen NINGUNA viva: AI088HH (2 filas) y NEA182 (8). NO ES UN BORRADO. 26 de las 29 filas tienen su fila en vehiculos_datos_colectivos, o sea que la ficha existe tambien para la retirada. Es una FUSION, y una fusion con plata adentro no la decide un carril: la decide Elazar. QUE HACE FALTA, en este orden: (1) medir la misma forma en PROD, solo SELECT; (2) decir por cada deuda a que fila apunta y si esa fila esta viva; (3) recien despues proponer la fusion, con el estado previo volcado. NO EJERCITADO: PROD; el contenido de las filas apareadas (solo se contaron referencias, no se comparo chasis/entidad/datos del colectivo); ninguna ficha abierta. RELACIONADO: MOVILBA-270 (la clase de dominios duplicados), MOVILBA-187 (rendiciones viva en prod).
Activity
-
db02 2026-09-05, MEDICION EN PROD. SOLO SELECT, ninguna escritura, ninguna tabla temporal. PROD = 10.78.42.168, base `movilba`, PostgreSQL 17.6. EL RESULTADO PRINCIPAL, Y CAMBIA LA PREGUNTA: EN PROD NO EXISTE LA TABLA. No existe `rendiciones.deudas_dominios`, no existe el esquema `rendiciones`, y no existe NINGUNA relacion cuyo nombre contenga 'deuda' o 'rendicion' en toda la base. Medido como superusuario contra pg_class + pg_namespace, no por to_regclass del rol de runtime, para no confundir "no existe" con "no lo puedo ver". Los unicos esquemas de PROD son bkp, public y rutap. Barrido al resto de las bases del host: `movilba_api` cero relaciones con ese nombre, `devandtesting` cero, `movilba_staging` no acepta conexiones. O sea que la deuda de rendiciones NO vive en Postgres del host de PROD. Rendiciones esta VIVA en PROD desde el 09-02 (MOVILBA-187) y su deuda se sirve desde otro lado - la API externa es el candidato, pero NO LO MEDI y no lo afirmo. CONSECUENCIA: la forma "plata colgando de una fila de vehiculo retirada" NO PUEDE existir en la base de PROD, porque el lado de la plata no esta ahi. Eso NO cierra el riesgo: lo mueve. La pregunta que queda abierta y que yo no puedo contestar desde Postgres es si el almacen real de la deuda referencia el vehiculo por ID (y entonces hereda exactamente este problema) o por DOMINIO (y entonces el problema es cual de las dos filas resuelve). Contestarla es leer el almacen de rendiciones, no esta base. LA CLASE DE DOMINIOS DUPLICADOS SI EXISTE EN PROD, Y ES MAS CHICA: - PROD: 2398 vehiculos, 10 retirados, 9 dominios con mas de una fila, 19 filas involucradas. - DEV: 2443 vehiculos, 11 dominios, 29 filas. - En PROD hay 0 dominios con mas de una fila VIVA (igual que DEV) y 0 dominios SIN ninguna fila viva. Los dos casos huerfanos de DEV (AI088HH y NEA182, este ultimo con OCHO filas) NO estan en PROD. NEA182 y AI088HH son de DEV solamente. - Los 9 de PROD: AE100DB, AE100DF, AE971GV, AF928IF, AG045KB (TRES filas, igual que en DEV), AH152NT, AI086GZ, AI086HB, PMH988. PMH988 es un caso que DEV no tiene. LA FORMA DEL DEFECTO ES LA MISMA EN LOS DOS ENTORNOS, y es la evidencia de que no es un accidente de DEV: la fila retirada es vieja (2025-12-08 en cinco casos, 2026-02-25 en dos) y la fila viva es del import de agosto (2026-08-05 en cuatro, 2026-08-14, 2026-08-25 en dos). En PROD ademas la fila retirada tiene CERO filas de historial en los nueve casos, mientras la viva tiene 1 a 4 - o sea que en PROD la fila vieja quedo sin historia y solo con su ficha (vehiculos_datos_colectivos = 1 en 17 de las 19 filas). En DEV hay dos dominios con historia de los DOS lados (AE100DB 1/6 y AE100DF 1/6); en PROD esos mismos dominios tienen 0/4. Esa diferencia es de DEV y hay que mirarla al fusionar. CAUSA, NO SINTOMA: el import de agosto creo una fila NUEVA en vez de reusar el id de la existente. Es exactamente lo que `reference_el_import_reconcilia_por_upsert_no_trunca` existe para impedir. Mientras el loader siga asi, fusionar estas filas es limpiar residuo con la causa corriendo. NO EJERCITADO: no lei el almacen real de la deuda de rendiciones (no es Postgres de PROD); no compare el CONTENIDO de las filas apareadas en PROD; no medi `movilba_staging` (no acepta conexiones); no toque nada - todas las sentencias fueron SELECT.
-
db03 re-measure 2026-09-18 04:40 (delegated by db02, SELECT-only, PROD, superuser query against pg_class+pg_namespace same method as db02 09-05). UNCHANGED: no schema 'rendiciones', no relation named deuda/rendicion anywhere in PROD Postgres (13 days later, same result as db02's original measurement). Cannot do step (2) - map each deuda->row + liveness - because the debt table is not readable from this DB; the store is external (API), confirmed absent again, not newly investigated. Duplicate-vehiculo substrate re-measured, UNCHANGED: same 9 dominios (AE100DB, AE100DF, AE971GV, AF928IF, AG045KB, AH152NT, AI086GZ, AI086HB, PMH988), 19 rows total, exactly 1 live row per dominio, 0 dominios with zero live rows. Per-row detail: retired side has 0 historial rows in all 9 pairs (vs 1-4 on the live side); 17 of 19 rows have a vdc ficha, 2 do not (AI086GZ id=5233, AI086HB id=5226, both retired). No new fusion proposed - Elazar's call per scope. No writes.
-
db03 2026-09-18 09:5x: intento de ejecutar 'copiar a PROD esquema+datos de rendiciones deuda' (delegado por db02, GO relayado por researcher). GATE 1 (vehiculo_id): NO HAY ninguna FK ni columna vehiculo_id en todo el esquema rendiciones (28 constraints enumerados via pg_constraint, todos internos al esquema); deudas_dominios solo tiene 'dominio' text UNIQUE. Copia segura de ese lado - no hereda el bug de MOVILBA-272 (fila retirada) via FK. GATE 2 (procedencia): SE CAE ACA, PREMISA MUERTA, NO EJECUTE. Las DOS tablas de deuda en DEV Postgres (10.9.10.54) son 100% filas de sync FALLIDO: deudas_dominios 100/100 filas con estado_sync='ERROR', importe=0, tiene_deuda=0 (todas NULL salvo un TRUE en la otra tabla); entidades_deudas_isib 23/23 con estado_sync='ERROR'. Las dos poblaciones ENTERAS son del mismo corte horario, 2026-09-16 14:40-15:17, un solo intento de sync que fallo de punta a punta. No hay una sola fila con deuda real sincronizada. No hay loader de rendiciones en este repo (grep de estado_sync sin resultados) asi que el sync corre afuera del boundary de este carril. Ademas la tabla rendiciones.rendiciones (3 filas) tiene 2 de 3 con razon_social literal 'Test srl'/'test srl', cuit 11-11111111-1 - fixtures, no dato real, coherente con la regla de Elazar de que DEV es descartable por default. VEREDICTO: no hay nada que copiar a PROD todavia. 'Copiar deuda de rendiciones' asume que DEV tiene deuda sincronizada y no la tiene - tiene el registro de un sync que fallo. Ejecutar la copia pondria 123 filas de error/cero en PROD como si fueran deuda real. No se escribio nada, no se toco PROD.
-
db03-mba-l-cc
-
db03 2026-09-18 ~12:30 ART. RE-MEASURED today (nothing taken from the stored 09-05 text), SELECT only, DEV (10.9.10.54 movilba_dev, PG15.17, movilba_user) + PROD (10.78.42.168 movilba, PG17.6, svc_nextjs - not superuser). Server identity read with inet_server_addr()+current_database() on both. RESULT: the premise no longer exists in either environment. Closing. 1. The shape "deuda -> retired vehiculo row" cannot exist by construction: no column in any rendiciones table holds a vehiculo id. rendiciones.deudas_dominios keys on `dominio` text (UNIQUE). pg_constraint: 0 FKs from rendiciones.* to public.*, 0 FKs into rendiciones.* (DEV; PROD has no such schema). 2. PROD: schema `rendiciones` does not exist in movilba (has_schema check + pg_class); the debt store is external, unreadable from this DB - step (1)-(2) of the ticket (measure PROD, map each debt to a row) is not answerable from a db lane, same as db03's 04:40 note. public.vehiculos in PROD: 2413 rows / 2413 live / 0 dominios with more than one row (count WITH and WITHOUT the borrado_en predicate: both 0). Live dominios absent from the current book (snapshot 2, 2413 dominios): 0. 3. DEV deudas_dominios: 100 rows / 100 distinct dominio, 100/100 estado_sync='ERROR', importe<>0: 0, tiene_deuda: 0, one failed sync run 2026-09-16 14:41-15:17 (matches db03's 09:5x note). Join by upper(dominio) to public.vehiculos: 100 resolve to exactly 1 live row, 0 to no row, 0 to retired-only, 0 to several. Control: the same join classified into the four buckets sums to 100 with no unassigned row. 4. The three original ids: 5920 and 5245 no longer exist in DEV (physically absent; 486 deleted 20 vehiculos in DEV today per db02 - I did not map these two ids to that delete). AI088HH has no vehiculos row in DEV or PROD and is not in the book (0 rows in v_rutap_latest_norm) - consistent with 'ausente del libro se borra fisico'; grep of docs/migrations for the dominio finds no case file. DHU474 in DEV = 6621 (retired 2026-09-08, chasis 'ASDASD55A55', a fixture retired by MOVILBA-342, see its header L42) + 6737 (live). FB444EP = 6723 retired + 6726 live. All four are origen_ingreso='app_dev' (user-created DEV test rows, outside 486's ssot_import delete predicate by design), not import residue and not in the book. Neither dominio has a debt row. NOT EXERCISED: PROD debt content (external store); whether the rendiciones API joins by dominio without a borrado_en filter (code in api-external is out of boundary); DEV vehiculos_datos_colectivos of the four fixture rows. Nothing to write; no DEV or PROD write was made.
-
db03 2026-09-18: closed on today's re-measurement, see the last event on this item.
-
db03 2026-09-18 ~12:30 ART, audit point 1 (coverage of 'PROD has no rendiciones schema'): re-run via pg_namespace as svc_nextjs (pg_namespace lists every schema regardless of USAGE): count(nspname='rendiciones')=0, count(nspname ilike '%rendic%')=0; non-system schemas in PROD movilba = public, bkp, rutap. So the absence is a catalog fact, not a permission-hidden one. The rendiciones API (MOVILBA-187, live 09-02) therefore does not store its debt data in this database; that store is external and was not read.
bug
5w ago by wi-cli-venus
4w ago
2026-09-18 15:22