Skip to content

docs(ops): FDD-OPS-019 — investigate Jira JQL pagination cap (BG short-fetch)#9

Merged
nascimentolimaandre-cloud merged 1 commit intomainfrom
feat/ops-019-jql-pagination-cap-investigation
Apr 30, 2026
Merged

docs(ops): FDD-OPS-019 — investigate Jira JQL pagination cap (BG short-fetch)#9
nascimentolimaandre-cloud merged 1 commit intomainfrom
feat/ops-019-jql-pagination-cap-investigation

Conversation

@nascimentolimaandre-cloud
Copy link
Copy Markdown
Owner

Summary

Documenta achado durante backfill comprehensive de 2026-04-30: projeto BG terminou com status='done' mas processou apenas ~64% das issues (126k de 197.760), sem error/crash/timeout. Hipótese principal: hard cap interno da Jira em cursor pagination com ORDER BY updated em buscas muito antigas (since=2020).

Por que abrir agora (ao invés de fix imediato)

Coverage atual após backfill é 54% tenant-wide (era 13% pré-fix). Métricas funcionam corretamente para os 240k issues frescos. Os ~72k BG issues "missing" mantém dados antigos mas:

  • Incremental sync corrige naturalmente quando elas são editadas no Jira
  • Aceitável para PoC + Webmotors demos
  • Não bloqueia R1

Crítico antes de enterprise tenants com projetos > 100k.

Investigation plan (proposto, S = 1 dia)

  1. Confirmar cap via instrumentação — log granular em fetch_issues_batched, capturar resposta crua quando nextPageToken vai vazio
  2. Workaround comprovado: date-chunking — quando pre-flight count > 100k, partir JQL em janelas de tempo (updated >= 2020 AND < 2022, etc.). Compatível com per-scope watermarks (FDD-OPS-014) e per-scope progress (FDD-OPS-015) já shippadas.
  3. Atomic JQL counting — validar somatório bate com approximate-count
  4. Fallback em produção — telemetria detecta items_done < items_estimate × 0.9 e cria event no pipeline_events

Acceptance criteria

Given a Jira project with > 100k issues
 When sync_worker runs full backfill (since=2020)
 Then either:
   (a) all >99% issues are fetched, OR
   (b) clear WARN log + pipeline_event identifies the under-fetch
       AND next cycle automatically retries the missing window

Given the date-chunking workaround is implemented
 When backfill runs on BG (197k issues)
 Then items_done >= 197000 (within 1% of estimate)
  AND total cycle duration < 90 min
  AND no batches lost or duplicated

Stats

  • 1 arquivo, +116 linhas (apenas backlog doc)
  • Code change deferido para sessão dedicada de implementação

🤖 Generated with Claude Code

…t-fetch)

OBSERVAÇÃO

Backfill comprehensive de 2026-04-30 (reset watermark issues → 2020-01-01)
processou apenas ~64% das issues do projeto BG (126k de 197.760), mesmo:
  - tracker.finish('done') chamado normalmente (sem error)
  - last_error NULL no pipeline_progress
  - approximate-count consistente em 197.762
  - coverage no DB confirma 197.760 BG issues existem

Iterator fetch_issues_batched terminou no caminho normal: nextPageToken
retornou vazio ou response.issues=[] após 126k. Não foi crash, timeout
nem retry esgotado.

HIPÓTESES (a investigar)
  1. Hard cap interno da Jira em pagination cursor com ORDER BY updated
     em busca muito antiga (since=2020 = ~5 anos)
  2. Limit não-documentado em /rest/api/3/search/jql (novo endpoint)
  3. approximate-count over-conta archived/deleted issues
  4. Race condition em refresh de índice durante sweep

WORKAROUND PROPOSTO

Date-chunking quando pre-flight count > 100k:
  jql = 'project = X AND updated >= START AND updated < END'
para chunks de ~2 anos. Já compatível com per-scope watermarks
(FDD-OPS-014) e per-scope progress (FDD-OPS-015).

IMPACTO ATUAL (não bloqueia R1)

Coverage tenant-wide ficou em 54% pós-backfill (era 13% pré-fix).
Os ~72k BG issues "missing" mantêm dados antigos mas:
  - Métricas para os 240k issues frescos funcionam corretamente
  - Incremental sync corrige naturalmente quando issues são updated
  - Aceitável para PoC + Webmotors demos

DECISÃO

Aceitar 54% e abrir investigação como FDD-OPS-019 P1 (S, 1 dia).
Crítico antes de enterprise tenants com projetos >100k.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@nascimentolimaandre-cloud nascimentolimaandre-cloud merged commit 6f8ed75 into main Apr 30, 2026
4 checks passed
@nascimentolimaandre-cloud nascimentolimaandre-cloud deleted the feat/ops-019-jql-pagination-cap-investigation branch April 30, 2026 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant