researchowl/KNOWN-ISSUES.md

# ResearchOwl — Known Issues & Operational Gotchas

## Brotli / aiohttp incompatibility

Do NOT install any brotli backend (`Brotli`, `brotlicffi`) while on aiohttp 3.14.x.
aiohttp's incremental brotli decompressor is broken and fails intermittently
depending on stream chunking ("Can not decode content-encoding: br" on VALID
streams — the same bytes decompress fine offline; httpx is unaffected).

Extra trap: merely *installing* a backend makes aiohttp advertise `br` in the
default `Accept-Encoding` of every session that doesn't set one explicitly.
On 2026-07-04 a scraper fix installed brotlicffi and inadvertently enabled br
project-wide: Ghost/Cloudflare responded in brotli, the decode blew up AFTER
Ghost had already accepted the POST, and the publish fallback re-published →
duplicate drafts + silently lost SEO notices.

Fix applied (commits `397546a` + `76c927f` + `7d07375`, guard relocated
2026-07-05):
- no brotli backend in requirements.txt (comment there explains why),
- explicit `Accept-Encoding: gzip, deflate` on all Ghost/autofill aiohttp
  sessions and on the scraper HEADERS (`57f341f`),
- duplicate guard INSIDE `GhostPublisher.publish_draft` (covers every caller,
  including `/publish`): if the POST is accepted (2xx) but reading the response
  fails, it recovers the just-created draft via `find_draft_by_title(title,
  since=attempt_start)` instead of raising. The guard only fires after an
  accepted POST — a pre-POST failure (Ollama down, menu fetch, links) never
  triggers it, so a stale same-title draft from a previous run can no longer
  swallow freshly generated content.

Note: with no backend installed there is NO brotli fallback at all — a server
that responds `Content-Encoding: br` without it being advertised (misbehaving
CDN) fails undecodable and that source is lost. Accepted trade-off.

The header value lives in one place: `SAFE_ACCEPT_ENCODING` in `src/config.py`.
Every aiohttp session/request must use it explicitly — never rely on aiohttp's
default Accept-Encoding, which silently grows `br` if a backend appears.

Re-test with disclosure.org before ever re-enabling br (e.g. after an aiohttp
upgrade).

## SQLite WAL mode + read-only mounts

The database runs in WAL mode, so even read-only access needs the `-shm` file
writable, or must open with `sqlite3 "file:...?immutable=1"`. Backups (daily
CronJob `researchowl-db-backup`, 03:00 Europe/Madrid, PVC `researchowl-backups`,
7-day retention) inherit WAL mode: to inspect one from a read-only mount use
`?immutable=1`; to restore, copy it to a writable location first.

## DDG (duckduckgo_search) blocks the event loop

`DDGS()` is synchronous (blocking requests inside). Never call it directly from
async code — always wrap in `loop.run_in_executor()` (see `_ddg_text_sync` /
`_ddg_videos_sync` in `src/scraper/exhaustive.py`). Direct calls froze the
entire Telegram bot during searches until fixed on 2026-07-04 (`8dfd011`).

## Google News RSS is a dead end from this infrastructure

`news.google.com/rss` entry links point to `/rss/articles/CBMi…` redirects that
hit a consent wall from EU IPs, and the inner `AU_yqL` id is only resolvable via
Google's private batchexecute API. Do not retry. The news seed uses Bing News
RSS instead (`ENABLE_NEWS_SEED`, real publisher URL in the `?url=` param of
apiclick.aspx — unwrapped by `_unwrap_news_link`).

## Large sources can OOM-kill the pod

On 2026-07-10 the pod was OOMKilled (memory limit was 1Gi) mid-research: a
batch of 20 concurrent sources hit a 98k-word document plus several large PDFs
at once, and pdfplumber's parse spiked RAM past the limit. The in-memory
research task died with the pod and its session sat in `running` forever.

Mitigations now in place:

- Memory limit raised to 2Gi (`k8s-manifests/researchowl/deployment.yaml`).
- PDFs capped at 15MB (was 50MB), checked both via Content-Length and actual
  body size; pdfplumber runs in `run_in_executor` (it is sync + CPU-heavy and
  also froze the event loop, same class of bug as DDGS) and flushes its page
  cache per page.
- Extracted content is truncated to `max_content_length` (300k chars) before
  hitting `source_contents`.
- On startup the bot marks orphaned `running` sessions as `interrupted`.

If a research still dies, the scraped sources survive in the DB: `/process`
re-chunks and scores them without re-scraping.

## Un shot spec escrito por Haiku falla de dos maneras concretas

Medido el 2026-08-01 generando Shorts de verdad contra sesiones reales (JAL
1628 #153, Bélgica #158). Las dos están mitigadas, pero conviene saber que
existen porque las dos son silenciosas si nadie mira.

**1. Comillas rectas dentro de una cadena JSON.** El modelo escribe
`"quote_a": ""CREDIBLE PEOPLE. THEY TOLD CLEARLY WHAT THEY SAW.""` y la cadena
se cierra en la segunda comilla: el JSON entero deja de parsear. Se repitió en
los tres intentos aunque el prompt lo prohíbe explícitamente y aunque el error
se le devolvía con el fragmento exacto. **No se arregla insistiendo**: lo
arregla `_typographic_inner_quotes()` en `src/generator/shortspec.py`, que
convierte esas comillas en `“ ”` recorriendo el texto con estado de cadena.
Sólo se ejecuta después de un fallo de parseo, así que un JSON correcto no pasa
por ahí. Además es lo que se quiere dibujar: las citas del canal van con
tipográficas.

**2. Se copian cifras del ejemplo del prompt.** El `examples/jal1628.json` que
va en el prompt como referencia de formato es también una fuente de datos muy
tentadora. En la primera eval dorada, tres claims del spec generado venían del
ejemplo y no de las fuentes: `232 FT` (largo de un 747) y `40 YEARS` no
aparecían en NINGUNO de los 126 chunks de la sesión, y `RARELY, IF EVER` estaba
en 1 chunk que no entró en el top-40 que vio el modelo. La sección 5 del prompt
lo dice ahora en mayúsculas ("FORMAT ONLY … a number copied from here is a
fabrication") y eso bajó de 3 a 1.

El ejemplo se queda con cifras reales a propósito — uno sintético enseña peor
la forma —, así que la defensa es estructural: `check_grounding()` contrasta lo
que no encuentra en los chunks **contra el propio ejemplo**, y lo que casa ahí
sale en el informe como `🧪 copiado del EJEMPLO del prompt (fuga, no
invención)`. Son dos diagnósticos y piden dos acciones: una invención hay que
verificarla, una fuga hay que borrarla.

Corolario: **el informe de claims no es decorativo**. Si algún día se manda el
vídeo sin él, se estará publicando lo que el modelo recuerde del ejemplo.

## El comprobador de fundamento sólo mira los chunks que vio el modelo

`check_grounding()` compara contra los mismos ~40 chunks que se metieron en el
prompt, no contra los 126 de la sesión. Es deliberado — la pregunta es "¿lo
sacó de lo que le dimos?" — pero produce falsos positivos cuando el dato existe
en la sesión y no entró en el top-k. Un falso positivo cuesta un vistazo; un
falso negativo cuesta la credibilidad del canal.