# Changelog of Euro Auctions Scraper — Europe Construction Equipment​‌​ (`rastriq/euroauctions-scraper`) Actor

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

## Changelog — Euro Auctions Scraper — Europe Construction Equipment​‌​

### 2026-09-18 — build FTP-28: E1, E2, E3

- T7 (push 2026-09-18): pot\_motor/tipo\_motor en preloaded\_sold/live ahora hacen fallback a title cuando description viene vacia (categoria engines: 0/10 -> deteccion cuando el dato de potencia vive en el titulo del lote, no en la descripcion).
- T6 (push 2026-09-18): mapper ftp28 whitelist 31 claves (extras -> ext\_\*); preloaded\_sold ya no usa literal "past-auction"; tipo="auction" via fallback a mc\_code cuando no hay categoria real (categoria queda None).

### 0.10.14 — 2026-09-08 (tag `latest`)

**Corregido**

- **`ref_anunciante` vuelve a llevar el auction ID** (formato de agosto), en las dos ramas
  (inventario activo y subastas cerradas). Decisión de David 2026-09-08: el pipeline del
  cliente está escrito contra el formato de agosto y esperaba el ID ahí. El valor sigue
  duplicado en `ext_auction_id`. Revierte el vaciado introducido en 0.10 sin perder el ext\_.
  Desplegado en Apify como build 0.10.14 vía API.

### 0.10 — 2026-08-25 (tag `beta`, sin promocionar)

**Corregido**

- `ref_anunciante` pasa a `None`. Contenía el identificador de la **subasta**, no del vendedor:
  **49 valores distintos para 80.522 lotes** al 100% de cobertura. `1031` es
  `Leeds - 8th, 9th, 10th & 11th July 2026`. En cualquier tabla resumen lucía como el mejor dato
  del perímetro mientras decía la fecha del evento.
  En Euro Auctions el vendedor es la propia casa de subastas; el consignatario no se publica.
- **`ext_auction_id` añadido a la rama de subastas cerradas.** Solo existía en la de inventario
  activo, así que vaciar `ref_anunciante` allí habría borrado el identificador sin dejar nada.

**Añadido**

- `_snapshot_dataset_name` en las dos ramas, con los **tres** puntos de publicación de puntero
  protegidos. El del inventario activo estaba sin proteger: una prueba en esa modalidad habría
  repuntado el snapshot del cliente igual.
- `_admin_snapshot` y `_snapshot_dataset_name` declarados en el input schema.

**Por qué NO se ha promocionado**

`ref_anunciante` pasa de **100% a 0%**. El dato no se pierde —está en `ext_auction_id`— pero si
el cliente mira cobertura verá un campo caer a cero de un mes para otro, y si algo de su ingesta
lo usa como clave, se rompe. **Hay que avisarlo antes.**

**Nota de plataforma**: el actor estaba en el límite de 10 versiones. Se borró la `v0.0` —vacía—
para crear ésta. Quedan tres versiones `dev` obsoletas por limpiar.

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.

### \[0.9] — 19 de agosto de 2026

#### Corregido — el volcado superaba el limite de payload y corrompia el puntero

Un `push` de 9.453.568 bytes contra el limite de 9.437.184 mataba el hilo. El run seguia
reportando exito y dejaba el puntero en 6.559 registros sobre un dataset de 20.702. Ahora el
volcado va en lotes de 500 y el hilo marca fallo, con `Actor.fail()`.

#### Reconstruido — el historico de subastas cerradas

De 12 subastas recogidas a **240 de 240**. Maestro consolidado: 422.893 registros, con precio de
cierre en el 100%.

#### Pendiente — sin ruta de entrada para las cerradas

`run_preloaded(inp)` resuelve **siempre** el puntero del inventario activo; `pastAuctions: true`
solo afecta al raspado en vivo. Quien pide las cerradas recibe el inventario activo, correctamente
formateado y sin ningun aviso. Es la unica de las dieciseis bases que no pasa la puerta de calidad.

Ademas `activeOnly` vale `True` por defecto y descarta cualquier item con precio de cierre — justo
los que forman el historico. El arreglo es el patron que ya usan Surplex y RB Auction:
`run_preloaded(inp, pointer_key=...)` elegido en el dispatch.

#### Pendiente — el puntero de cerradas apunta solo al mes

`euroauctions-scraper-past` resuelve a `euroauctions-scraper-past-2026-08` (80.522), no al historico
consolidado de 422.893.

### 0.10 — builds 0.10.6 a 0.10.10 — 2026-08-29

**Corregido — QA: actor marcado "Under maintenance"**

El prefill de `input_schema.json` tenía dos problemas que hacían fallar el 100% de los tests
automáticos de Apify:

1. `data_freshness: "live"` forzaba un raspado en vivo innecesario para la validación de QA.
2. `proxyConfiguration: { useApifyProxy: false }` dejaba la petición sin proxy. La API de
   Euro Auctions devuelve **HTTP 403** desde IPs de datacenter; sin proxy residencial o de Apify,
   todos los runs de QA fallaban.

Corregido: `data_freshness` prefill → `"preloaded"`, `proxyConfiguration` prefill →
`{ useApifyProxy: true }`. El pretest de QA pasa en 3.9 s, 10 items, $0.0000.

**Añadido — proxy residencial Decodo (Smartproxy)**

Integración de Decodo como proxy primario, con Apify proxy como fallback:

- Variable de entorno `DECODO_PROXY` (secreto, formato `userid:password`).
- `_get_decodo_proxy()` construye la URL: `http://user-{userid}-sessionduration-{min}:{pass}@gate.decodo.com:{port}`.
- Prioridad: Decodo → Apify proxy → sin proxy.
- Defaults: `port=10010`, `sticky_minutes=30`.

**Cambiado — parámetros por defecto de Decodo**

- Puerto: `10001` → `10010` (gateway residencial HTTP actualizado).
- Sticky session: `60` min → `30` min (reduce coste sin afectar a la extracción).

**Verificado**

- Smoke test preloaded: 3.9 s, 10 items, coste $0.0000.
- Smoke test live con Decodo: 8 s, 3 items, proxy "Decodo sticky-30min (UK pool)" confirmado en logs.
- API Euro Auctions devuelve 403 sin proxy (confirmado con curl desde IP datacenter).