Descrição
Auditoria decorrente do bug corrigido no #1783 (a migração para Prefect 3 fez poll_source_for_update comparar Table.Update.latest — timestamp de execução — em vez de Coverage.DateTimeRange — competência real; casos confirmados: br_me_caged #1760 e br_ans_beneficiario). A hipótese era que outros flows pudessem ter a mesma lacuna silenciosa.
Verificamos manualmente 58 tabelas cruzando três fontes: Coverage.DateTimeRange (GraphQL), dado real no BigQuery (SELECT MAX(...) nas colunas de competência, partition-pruned, via credencial de prod) e Table.Update.latest atual (GraphQL).
Resultado: em 57 das 58 tabelas, Coverage é fiel ao BigQuery. O bug do #1783 não se repetiu em nenhum outro caso verificado — onde há lacuna de dado, é execução de flow/crawler, não comparação de metadado errada. A única exceção é br_ms_sinan.microdados_dengue, onde o próprio Coverage (não só Table.Update) ficou 5 meses atrás do BigQuery real.
Isso é relevante pra esta chore porque Table.Update.latest, ao contrário do Coverage, não tinha sido validado sistematicamente até agora — é o campo que esta issue propõe atualizar com os metadados reais da API do BigQuery. A tabela em "Escopo afetado" dá o valor atual e a referência de competência real do BigQuery pra cada tabela verificada.
Escopo afetado
Tabela completa — 58 tabelas verificadas
| Dataset.tabela |
Table.Update.latest atual |
Max real (BigQuery) |
Coverage bate com o BigQuery? |
br_ibge_ipca.mes_brasil |
2026-08-13 (relógio) |
2026-06 |
✅ |
br_ibge_ipca15.mes_brasil |
2026-06-26 (relógio) |
2026-06 |
✅ |
br_ibge_inpc.mes_brasil |
2026-08-13 (relógio) |
2026-07 |
✅ |
br_bcb_estban.agencia |
2026-08-19 (relógio) |
2026-03 |
✅ |
br_denatran_frota.uf_tipo |
2026-08-19 (relógio) |
2026-07 |
✅ |
br_anp_precos_combustiveis.microdados |
2026-08-15 (relógio) |
2026-08-14 |
✅ |
br_inmet_bdmep.microdados |
2026-08-10 (relógio) |
2026-07-31 |
✅ |
br_rf_cnpj.empresas |
2026-08-14 (relógio) |
2026-08-01 |
✅ |
br_rf_cnpj.estabelecimentos |
2026-08-14 (relógio) |
2026-08-01 |
✅ |
br_rf_cnpj.socios |
2026-08-14 (relógio) |
2026-08-01 |
✅ |
br_cgu_cartao_pagamento.microdados_governo_federal |
2026-08-13 (relógio) |
2026-07 |
✅ |
br_cgu_servidores_executivo_federal.cadastro_servidores |
2026-08-13 (relógio) |
2026-06 |
✅ |
br_ms_sih.aihs_reduzidas |
2026-06-13 (relógio) |
2026-04 |
✅ |
br_ms_sia.producao_ambulatorial |
2026-07-11 (relógio) |
2026-05 |
✅ |
br_anatel_banda_larga_fixa.microdados |
2026-08-13 (relógio) |
2026-06 |
✅ |
br_anatel_telefonia_movel.microdados |
2026-08-17 (relógio) |
2026-06 |
✅ |
br_cgu_licitacao_contrato.contrato_compra |
2026-04-05 (relógio, parado) |
2026-05 |
🟡 ~1 mês atrás do real |
br_cgu_licitacao_contrato.contrato_item |
2026-04-04 (relógio, parado) |
2026-05 |
🟡 ~1 mês atrás do real |
br_cgu_licitacao_contrato.contrato_termo_aditivo |
2026-04-04 (relógio, parado) |
2026-05 |
🟡 ~1 mês atrás do real |
br_cgu_beneficios_cidadao.bpc |
2026-08-10 (relógio) |
2026-06 |
✅ |
br_cgu_beneficios_cidadao.garantia_safra |
2026-07-10 (relógio) |
2026-06 |
✅ |
br_cgu_beneficios_cidadao.novo_bolsa_familia |
2026-08-11 (relógio) |
2026-06 |
✅ |
br_rf_cno.areas |
2026-08-19 (relógio) |
2026-08-19 |
✅ |
br_rf_cno.cnaes |
2026-08-19 (relógio) |
2026-08-19 |
✅ |
br_rf_cno.microdados |
2026-08-19 (relógio) |
2026-08-19 |
✅ |
br_rf_cno.vinculos |
2026-08-19 (relógio) |
2026-08-19 |
✅ |
br_rf_cafir.imoveis_rurais |
2026-08-03 (relógio) |
2026-08-02 |
✅ |
br_bcb_agencia.agencia |
2026-07-26 (relógio) |
2026-06 |
✅ |
br_stf_corte_aberta.decisoes |
2025-03-03 (relógio, parado) |
2025-03-02 |
✅ |
br_bcb_taxa_selic.taxa_selic |
2025-09-23 (relógio, parado) |
2025-03-25 |
✅ |
br_me_siconfi.municipio_receitas_orcamentarias |
2026-08-01 (relógio) |
2025 |
✅ |
br_mf_divida_ativa.nao_previdenciario |
2026-08-08 (relógio) |
2026-T2 |
✅ |
br_sedec_desastres.reconhecimentos_vigentes |
2026-08-12 (relógio) |
2026-08-06 |
✅ |
mx_sesnsp_incidencia_delictiva.municipio_delitos |
2026-08-12 (relógio) |
2026-06 |
✅ |
world_wb_wdi.data |
2022-12-30 (relógio, parado) |
2025 |
✅ |
au_abs_cpi.monthly |
2026-08-05 (relógio) |
2026-06 |
✅ |
au_abs_labour_force.labour_force_status |
2026-08-06 (relógio) |
2026-06 |
✅ |
us_bls_cpi.monthly |
2026-08-13 (relógio) |
2026-07 |
✅ |
us_bls_qcew.naics_quarterly_national |
2026-08-03 (relógio) |
2025-Q4 |
✅ |
world_cricsheet.matches |
2026-08-01 (relógio) |
2026-07-30 |
✅ |
br_me_comex_stat.ncm_exportacao |
2026-07-01 (cobertura, corrigido) |
2026-07 |
✅ |
br_me_comex_stat.ncm_importacao |
2026-07-01 (cobertura, corrigido) |
2026-07 |
✅ |
br_me_comex_stat.municipio_exportacao |
2026-07-01 (cobertura, corrigido) |
2026-07 |
✅ |
br_me_comex_stat.municipio_importacao |
2026-07-01 (cobertura, corrigido) |
2026-07 |
✅ |
br_ms_cnes.profissional |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.estabelecimento |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.equipe |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.equipamento |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.dados_complementares |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.estabelecimento_filantropico |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.gestao_metas |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.habilitacao |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.incentivos |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.servico_especializado |
2026-07-01 (cobertura) |
2026-07 |
✅ |
br_ms_cnes.leito |
2026-05-01 (cobertura) |
2026-05 |
✅ |
br_ms_cnes.estabelecimento_ensino |
2024-05-16 (relógio, sem cron) |
2019-12 |
✅ |
br_ms_cnes.regra_contratual |
2024-05-16 (relógio, sem cron) |
2023-07 |
✅ |
br_ms_sinan.microdados_dengue |
2026-01-23 |
2026-06-29 |
❌ Coverage também desatualizado — única exceção |
Prioridade de correção — flows com sinal claro de execução parada
Nestes casos, o timestamp em si mostra que a última execução bem-sucedida foi há muito tempo — atualizar o campo via API do BigQuery vai revelar uma lacuna de dado real, não só corrigir o timestamp:
- 🔴🔴
br_stf_corte_aberta.decisoes — última run 2025-03-03 (17,5 meses parado)
- 🔴🔴
br_bcb_taxa_selic.taxa_selic — última run 2025-09-23 (17 meses parado)
- 🔴
br_ms_sinan.microdados_dengue — único caso onde o Coverage também está errado (não só Table.Update); o BigQuery já tem 5 meses de dado além do que o metadado registra
- 🔴
br_cgu_licitacao_contrato (3 tabelas) — última run ~04-05/04/2026 (~4,5 meses parado)
- 🟡
world_wb_wdi.data — última run 2022-12-30 (quase 4 anos); vale confirmar se foi descontinuado de propósito antes de "corrigir"
- 🟡
br_ms_cnes.estabelecimento_ensino (parado desde 2019-12) e .regra_contratual (desde 2023-07) — sem cron agendado no código, então a staleness pode ser proposital
Observações para quem for implementar
- Atualizar o timestamp não resolve a causa raiz nos 6 casos acima — o BigQuery vai confirmar que a tabela está genuinamente desatualizada, não que o metadado mentia. Vale abrir issues de acompanhamento separadas pra investigar por que esses flows pararam de rodar (histórico de execução no Prefect), especialmente
br_stf_corte_aberta e br_bcb_taxa_selic.
br_me_cnpj não tem nenhum registro de Table/Update/Coverage no backend (allCloudtable retorna vazio, apesar das tabelas existirem no BigQuery) — fora do escopo desta chore até esse registro existir ou o dataset ser formalmente descontinuado em favor do br_rf_cnpj.- TSE eleições usa uma lógica de detecção própria (contagem de linhas contra a base de prod, não uma comparação direta de datas) — não foi auditado a fundo e pode precisar de tratamento especial na implementação.
- Todos os valores de "Max real (BigQuery)" acima vieram de
SELECT MAX(...)/ORDER BY ... LIMIT 1 nas colunas de competência de cada tabela (não do metadado lastModifiedTime do recurso BigQuery) — quem implementar a chore deve confirmar qual API/campo específico da BigQuery API pretende usar como fonte de verdade, já que os dois conceitos (competência dos dados vs. timestamp de escrita da tabela) são diferentes.
Referências
Descrição
Auditoria decorrente do bug corrigido no #1783 (a migração para Prefect 3 fez
poll_source_for_updatecompararTable.Update.latest— timestamp de execução — em vez deCoverage.DateTimeRange— competência real; casos confirmados:br_me_caged#1760 ebr_ans_beneficiario). A hipótese era que outros flows pudessem ter a mesma lacuna silenciosa.Verificamos manualmente 58 tabelas cruzando três fontes:
Coverage.DateTimeRange(GraphQL), dado real no BigQuery (SELECT MAX(...)nas colunas de competência, partition-pruned, via credencial de prod) eTable.Update.latestatual (GraphQL).Resultado: em 57 das 58 tabelas,
Coverageé fiel ao BigQuery. O bug do #1783 não se repetiu em nenhum outro caso verificado — onde há lacuna de dado, é execução de flow/crawler, não comparação de metadado errada. A única exceção ébr_ms_sinan.microdados_dengue, onde o próprioCoverage(não sóTable.Update) ficou 5 meses atrás do BigQuery real.Isso é relevante pra esta chore porque
Table.Update.latest, ao contrário doCoverage, não tinha sido validado sistematicamente até agora — é o campo que esta issue propõe atualizar com os metadados reais da API do BigQuery. A tabela em "Escopo afetado" dá o valor atual e a referência de competência real do BigQuery pra cada tabela verificada.Escopo afetado
Tabela completa — 58 tabelas verificadas
Table.Update.latestatualCoveragebate com o BigQuery?br_ibge_ipca.mes_brasilbr_ibge_ipca15.mes_brasilbr_ibge_inpc.mes_brasilbr_bcb_estban.agenciabr_denatran_frota.uf_tipobr_anp_precos_combustiveis.microdadosbr_inmet_bdmep.microdadosbr_rf_cnpj.empresasbr_rf_cnpj.estabelecimentosbr_rf_cnpj.sociosbr_cgu_cartao_pagamento.microdados_governo_federalbr_cgu_servidores_executivo_federal.cadastro_servidoresbr_ms_sih.aihs_reduzidasbr_ms_sia.producao_ambulatorialbr_anatel_banda_larga_fixa.microdadosbr_anatel_telefonia_movel.microdadosbr_cgu_licitacao_contrato.contrato_comprabr_cgu_licitacao_contrato.contrato_itembr_cgu_licitacao_contrato.contrato_termo_aditivobr_cgu_beneficios_cidadao.bpcbr_cgu_beneficios_cidadao.garantia_safrabr_cgu_beneficios_cidadao.novo_bolsa_familiabr_rf_cno.areasbr_rf_cno.cnaesbr_rf_cno.microdadosbr_rf_cno.vinculosbr_rf_cafir.imoveis_ruraisbr_bcb_agencia.agenciabr_stf_corte_aberta.decisoesbr_bcb_taxa_selic.taxa_selicbr_me_siconfi.municipio_receitas_orcamentariasbr_mf_divida_ativa.nao_previdenciariobr_sedec_desastres.reconhecimentos_vigentesmx_sesnsp_incidencia_delictiva.municipio_delitosworld_wb_wdi.dataau_abs_cpi.monthlyau_abs_labour_force.labour_force_statusus_bls_cpi.monthlyus_bls_qcew.naics_quarterly_nationalworld_cricsheet.matchesbr_me_comex_stat.ncm_exportacaobr_me_comex_stat.ncm_importacaobr_me_comex_stat.municipio_exportacaobr_me_comex_stat.municipio_importacaobr_ms_cnes.profissionalbr_ms_cnes.estabelecimentobr_ms_cnes.equipebr_ms_cnes.equipamentobr_ms_cnes.dados_complementaresbr_ms_cnes.estabelecimento_filantropicobr_ms_cnes.gestao_metasbr_ms_cnes.habilitacaobr_ms_cnes.incentivosbr_ms_cnes.servico_especializadobr_ms_cnes.leitobr_ms_cnes.estabelecimento_ensinobr_ms_cnes.regra_contratualbr_ms_sinan.microdados_denguePrioridade de correção — flows com sinal claro de execução parada
Nestes casos, o timestamp em si mostra que a última execução bem-sucedida foi há muito tempo — atualizar o campo via API do BigQuery vai revelar uma lacuna de dado real, não só corrigir o timestamp:
br_stf_corte_aberta.decisoes— última run 2025-03-03 (17,5 meses parado)br_bcb_taxa_selic.taxa_selic— última run 2025-09-23 (17 meses parado)br_ms_sinan.microdados_dengue— único caso onde oCoveragetambém está errado (não sóTable.Update); o BigQuery já tem 5 meses de dado além do que o metadado registrabr_cgu_licitacao_contrato(3 tabelas) — última run ~04-05/04/2026 (~4,5 meses parado)world_wb_wdi.data— última run 2022-12-30 (quase 4 anos); vale confirmar se foi descontinuado de propósito antes de "corrigir"br_ms_cnes.estabelecimento_ensino(parado desde 2019-12) e.regra_contratual(desde 2023-07) — sem cron agendado no código, então a staleness pode ser propositalObservações para quem for implementar
br_stf_corte_abertaebr_bcb_taxa_selic.br_me_cnpjnão tem nenhum registro deTable/Update/Coverageno backend (allCloudtableretorna vazio, apesar das tabelas existirem no BigQuery) — fora do escopo desta chore até esse registro existir ou o dataset ser formalmente descontinuado em favor dobr_rf_cnpj.SELECT MAX(...)/ORDER BY ... LIMIT 1nas colunas de competência de cada tabela (não do metadadolastModifiedTimedo recurso BigQuery) — quem implementar a chore deve confirmar qual API/campo específico da BigQuery API pretende usar como fonte de verdade, já que os dois conceitos (competência dos dados vs. timestamp de escrita da tabela) são diferentes.Referências
compare_againstempoll_source_for_update, causa raiz do bug de comparaçãobr_me_cagednão detectava atualizações do CAGED (primeiro caso confirmado)br_ans_beneficiario— segundo caso confirmado, corrigido na mesma janela