tech-debt: 8 métodos de resolver chamam datasource methods inexistentes

[nitaibezerra]

Contexto

Descoberto durante validação da Fase R1 (PR #2, lifespan + DS init real) em staging. Após corrigir o bug do NoneType (datasources não inicializados), descobri que vários resolvers chamam métodos que não existem nos datasources.

A migração R1 só ativou graphql.clippings por enquanto, e todos os métodos necessários para esse flow existem. Os 8 gaps abaixo bloqueiam ativação das próximas flags (graphql.marketplace, etc) e chamadas de workers/Composer.

Auditoria

diff <(grep -rE "ds\.(get|search|list|find|create|update|delete)_\w+" src/graphql_api/schema/resolvers \
      | sed -E 's/.*ds\.([a-z_]+).*/\1/' | sort -u) \
     <(grep -rE "^\s+def (get|search|list|find|create|update|delete)_\w+" src/graphql_api/datasources \
      | sed -E 's/.*def ([a-z_]+).*/\1/' | sort -u)

Métodos chamados mas não implementados

Método	Resolver	Bloqueia
get_marketplace_listing	schema/resolvers/marketplace.py	flag graphql.marketplace
get_marketplace_listings	schema/resolvers/marketplace.py:82	flag graphql.marketplace
get_integrity_batch	schema/resolvers/analytics.py (?)	Composer/DAGs
get_news_batch	schema/resolvers/news.py (?)	Composer
get_news_batch_for_bigquery	schema/resolvers/news.py (?)	Composer/BigQuery
get_news_by_id	schema/resolvers/news.py (?)	Flag futura
get_news_for_typesense	schema/resolvers/news.py (?)	typesense-sync-worker
get_similar_articles	schema/resolvers/articles.py (?)	Portal (similar articles widget?)

Confirmar localização exata de cada resolver e qual datasource deveria expor o método.

Evidência

Smoke test em staging pós-merge do PR #2:

$ curl -sS -X POST -H "Content-Type: application/json" \
    -d '{"query":"{ marketplaceListings(page: 1) { listings { id name } } }"}' \
    https://destaquesgovbr-graphql-api-klvx64dufq-rj.a.run.app/graphql
{"errors":[{"message":"'FirestoreDatasource' object has no attribute 'get_marketplace_listings'", ...}]}

Como deveria ter sido evitado

TDD ou teste de integração que chama cada query do schema sem mock detectaria todos esses gaps no CI. Os testes existentes em tests/resolvers/ usam mocks (MagicMock) que respondem a qualquer método, mascarando o gap.

Sugestão: adicionar smoke test parametrizado em tests/integration/ que itera por todas queries públicas do schema e verifica que o resolver não levanta AttributeError.

Critério de pronto

• Cada método acima implementado nos datasources apropriados (Firestore para marketplace/clippings; provavelmente Postgres para news/integrity/bigquery)
• Smoke parametrizado adicionado para prevenir regressão
• Smoke teste em staging passa para marketplaceListings antes de ativar graphql.marketplace

Prioridade

Bloqueia ativação das flags 2-5 do RUNBOOK-R1.md (marketplace, agent, push, widgets) e queries de Composer/Airflow.