# 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.