# Changelog of Ritchie Bros Scraper — Heavy Equipment Auctions (`rastriq/rbauction-scraper`) Actor

- **URL**: https://apify.com/rastriq/rbauction-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/rastriq/rbauction-scraper.md

## Changelog — Ritchie Bros Scraper — Heavy Equipment Auctions

### 2026-10-04 — tiempo_uso con unidad (pendiente build, aprobación David)

- `ext_tiempo_uso_unidad` (h|km|mi|null) y `ext_tiempo_uso_calidad` (cero|horas_igual_km|unidad_sin_confirmar|null) en `_rb_to_ftp` (live, preloaded crudo, snapshot sold) y, para registros ya almacenados en FTP-28 o inglés+ext (master de remates), vía `_fill_uso_rb` idempotente en `_to_out`, sin re-scrapear. Formato de `tiempo_uso` intacto ("N h" / "N km" / "N mi"; millas SIN convertir). Único cambio de valor: horas=0 con km/mi ya no devuelve "0 h" ocultando el km. Medición (muestras sept): active 1000 -> 591 con uso antes y después (546 h, 45 km, 0 mi); sold 2000 -> 1043 (609 h, 434 km, 0 mi); hours en esquema inglés idéntico en el 100 %. Declaradas en dataset_schema.json.

### 2026-09-18 — build FTP-28: R1

- T7 (push 2026-09-18): \_update_pointer hace merge sobre el pointer existente en vez de sobrescribirlo entero, preservando el campo "master" (historyScope=full) que un snapshot delta mensual borraba silenciosamente en cada actualizacion.

Formato: que cambio, por que, y **la medicion que lo respalda**. Un cambio sin numero detras es
una opinion; en este repo no cuenta como entrada de changelog.

Las versiones son las de Apify (`mayor.menor`). La plataforma no admite numero de parche.

### \[1.0] — 20 de agosto de 2026

#### Corregido — el modo remates emitia cero registros

El esquema de entrada declara `listingStatuses: ["Open"]` por defecto y **Apify lo inyecta en toda
ejecucion aunque el cliente no lo escriba**. Contra un snapshot que es 100% `Sold`, ese filtro
descartaba los 1,5 M de registros uno a uno: el run recorria el dataset entero, emitia cero y moria
por timeout. `runPreset: "custom"` no lo corregia, porque el valor lo pone el esquema, no el preset.

Medido con el mismo input, antes y despues:

```
antes    4 min 00 s -> 0 registros -> timeout
despues  0,74 s     -> 1.000 registros
```

Se diagnostico durante tres dias como lentitud de lectura. Era filtrado.

#### Corregido — el esquema ingles del maestro no se convertia a FTP-28

`run_preloaded` reconocia dos formas —FTP-28 y el payload crudo de la API— pero no la tercera: el
ingles + `ext_*` del maestro de remates. La pasaba por `_rb_to_ftp`, que solo entiende claves
camelCase, y devolvia marca, modelo, anio y precio a `null`. Mismo patron que tuvo mobile.de.

#### Corregido — `url` salia en la posicion 31 en vez de la 5

Se llama igual en los dos esquemas, asi que caia por el bloque de campos no mapeados. Los 31 campos
FTP-28 ya salen en orden canonico exacto.

#### Corregido — emitir cero ya no termina en `SUCCEEDED`

Si el run recorre el snapshot entero sin emitir nada, `Actor.fail()` con el motivo. Un fallo
silencioso llega al cliente sin que nadie se entere.

#### Anadido — `soldFrom` / `soldTo`

Filtran por **fecha de martillo** (`ext_gql_sold_time_iso`), no por mes de raspado. El maestro
entero cuesta ~$2.876 por ejecucion; el incremento de agosto son 24.790 registros por ~$47.
Verificado: 24.790 emitidos en 6 min 18 s, todos con `valor` y `moneda`.

`snapshotMonth` no sirve para esto: filtra por mes de raspado, y en un maestro acumulativo los
1,5 M de registros llevan solo dos fechas de raspado repartidas sobre dos anos.

#### Reconstruido — el maestro de remates

Mezclaba dos esquemas incompatibles: sus primeras 52.856 filas eran el payload crudo de la API de
Ritchie (80 campos camelCase, sin `item_id`, sin `source`) concatenadas delante del cuerpo
normalizado. Y arrastraba 791.587 filas duplicadas.

| | antes | despues |
|---|---:|---:|
| Filas | 2.252.925 | 1.513.925 |
| `item_id` unicos | 1.461.338 | 1.513.925 |
| Duplicados | 791.587 (35%) | 0 |
| Esquemas | 2 | 1 |
| Con precio de cierre | — | 98,9% |

Baja de 2,25 M a 1,51 M **quitando duplicados, no cobertura**: en anuncios unicos sube.

#### Rectificado — el diagnostico de "97,7% sin precio de cierre" era falso

Se midio consultando `gql_soldPrice`, nombre que solo usaba un bloque minoritario del maestro. El
96,9% llevaba el precio en `ext_gql_sold_price`. No hubo token caducado. **Al comprobar la cobertura
de un campo, buscarlo por sufijo, nunca por nombre exacto.**