Detectado en la revisión del PR #45.
_filter_in_range compara item.created_at contra bounds tz-aware. En el flujo de extract en vivo created_at siempre es tz-aware (_parse_x_date usa %z o cae a datetime.now(timezone.utc)), así que no crashea hoy. Pero el modelo Item NO fuerza tz-awareness en created_at (a diferencia de los timestamps de media, que usan _require_utc_aware). Un Item con created_at naive (items.json editado a mano, item construido directamente, o un productor futuro) pasado a _filter_in_range con un bound aware lanza TypeError: can't compare offset-naive and offset-aware datetimes.
Fix propuesto: añadir un validador tz-aware a Item.created_at (reutilizar _require_utc_aware de models.py), o coercer/guardar dentro de _filter_in_range. Baja severidad (no alcanzable por el pipeline actual), pero es un landmine latente que el nuevo helper puro invita al reusarse.
Detectado en la revisión del PR #45.
_filter_in_rangecomparaitem.created_atcontra bounds tz-aware. En el flujo de extract en vivocreated_atsiempre es tz-aware (_parse_x_dateusa%zo cae adatetime.now(timezone.utc)), así que no crashea hoy. Pero el modeloItemNO fuerza tz-awareness encreated_at(a diferencia de los timestamps de media, que usan_require_utc_aware). UnItemconcreated_atnaive (items.json editado a mano, item construido directamente, o un productor futuro) pasado a_filter_in_rangecon un bound aware lanzaTypeError: can't compare offset-naive and offset-aware datetimes.Fix propuesto: añadir un validador tz-aware a
Item.created_at(reutilizar_require_utc_awarede models.py), o coercer/guardar dentro de_filter_in_range. Baja severidad (no alcanzable por el pipeline actual), pero es un landmine latente que el nuevo helper puro invita al reusarse.