106 lines
2.5 KiB
Markdown
106 lines
2.5 KiB
Markdown
# Trip Status Null Debug Runbook
|
|
|
|
## Objetivo
|
|
Identificar si los `null` en `c_cambios_estado` (campos `latitud`, `longitud`, `id_transportista`, `n_proveedor`) se originan en:
|
|
- payload recibido,
|
|
- resolución de identidad/proveedor en backend,
|
|
- o persistencia final en base de datos.
|
|
|
|
## 1) Correlacionar por request_id en logs
|
|
|
|
### POST crudo recibido
|
|
```bash
|
|
rg -n '"request_id":"<REQUEST_ID>"' /var/log/posts.log
|
|
```
|
|
|
|
### Flujo de estado manual/automático en status.log
|
|
```bash
|
|
rg -n "\"request_id\":\"<REQUEST_ID>\"" /var/log/status.log
|
|
```
|
|
|
|
### Trazas internas del controlador (stdout/stderr de la API)
|
|
```bash
|
|
rg -n "<REQUEST_ID>|TripStatusDebug|TripStatusAudit" /tmp/node-gestion-api.log
|
|
```
|
|
|
|
## 2) Verificar última persistencia en c_cambios_estado
|
|
|
|
### Último estado de un viaje para un estado concreto
|
|
```sql
|
|
SELECT
|
|
id_viaje,
|
|
id_estado,
|
|
n_proveedor,
|
|
id_transportista,
|
|
latitud,
|
|
longitud,
|
|
ind_fallido,
|
|
incidencia,
|
|
fecha_y_hora,
|
|
id_usuario
|
|
FROM c_cambios_estado
|
|
WHERE id_viaje = ? AND id_estado = ?
|
|
ORDER BY fecha_y_hora DESC
|
|
LIMIT 1;
|
|
```
|
|
|
|
### Últimos cambios del viaje (timeline)
|
|
```sql
|
|
SELECT
|
|
id_viaje,
|
|
id_estado,
|
|
n_proveedor,
|
|
id_transportista,
|
|
latitud,
|
|
longitud,
|
|
fecha_y_hora
|
|
FROM c_cambios_estado
|
|
WHERE id_viaje = ?
|
|
ORDER BY fecha_y_hora DESC
|
|
LIMIT 20;
|
|
```
|
|
|
|
## 3) Verificar resolución proveedor/transportista (fuente backend)
|
|
|
|
### Relación viaje + DNI
|
|
```sql
|
|
SELECT
|
|
id_viaje,
|
|
dni,
|
|
n_proveedor,
|
|
id_proveedor,
|
|
fecha_salida
|
|
FROM c_viajes_proveedor
|
|
WHERE id_viaje = ? AND dni = ?
|
|
ORDER BY n_proveedor ASC;
|
|
```
|
|
|
|
### Detectar filas problemáticas con n_proveedor nulo
|
|
```sql
|
|
SELECT
|
|
id_viaje,
|
|
dni,
|
|
n_proveedor,
|
|
id_proveedor
|
|
FROM c_viajes_proveedor
|
|
WHERE id_viaje = ? AND n_proveedor IS NULL;
|
|
```
|
|
|
|
## 4) Verificación temporal sin request_id (fallback)
|
|
|
|
Si no hay `request_id`, cruzar por ventana temporal:
|
|
1. Tomar `timestamp` del POST en `/var/log/posts.log`.
|
|
2. Buscar en `/var/log/status.log` en +/- 5 segundos por `trip_id`.
|
|
3. Validar `fecha_y_hora` en `c_cambios_estado` para ese `trip_id` e `id_estado`.
|
|
|
|
## 5) Interpretación rápida
|
|
|
|
- `posts.log` trae lat/long válidas y en debug aparecen normalizadas a `null`:
|
|
- falla de normalización/parseo.
|
|
- `dni_from_token` presente pero `resolved_n_proveedor = null`:
|
|
- inconsistencia en `c_viajes_proveedor`.
|
|
- debug de persistencia muestra valores correctos pero BD tiene otros:
|
|
- revisar triggers/procesos posteriores o concurrencia.
|
|
- debug de persistencia ya muestra `null`:
|
|
- origen en backend previo al insert/update.
|