[Bugfix] br_cgu_beneficios_cidadao - #1780
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe CGU benefícios cidadão flow assigns source formats per table and propagates them to staging and production GCS uploads. Flow documentation now describes source-format handling and related execution behavior. ChangesBenefícios cidadão source format propagation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pipelines/crawler/cgu/flows.py`:
- Around line 60-68: The _materialize_and_metadata function needs a Google-style
docstring documenting its source_format parameter. State that source_format
controls both GCS uploads and must match the file format produced by the
partitioning step, while preserving the existing type hints and behavior.
- Line 38: Wrap the comment beginning “Formato em que cada tabela do
br_cgu_beneficios_cidadao” in flows.py so each resulting comment line is at most
79 characters, preserving its meaning.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 8c628354-6603-436c-b03a-3fdd69aca664
📒 Files selected for processing (2)
pipelines/crawler/cgu/flows.pypipelines/datasets/br_cgu_beneficios_cidadao/flows.py
|
Tick the box to add this pull request to the merge queue (same as
|
Descrição do PR
As runs do
novo_bolsa_familiae dagarantia_saframorrem comFileNotFoundError: Nenhum arquivo csv encontrado em /tmp/output/<tabela>logo depois departicionar. Este PR faz cada tabela declarar no upload o formato em que ela é de fato
gravada em disco.
falha acontece antes de qualquer escrita, então nada em produção foi corrompido — as
tabelas só não avançam.
Detalhes Técnicos
Principais alterações na pipeline/scripts:
pipelines/crawler/cgu/flows.pyganha ummapa de
source_formatpor tabela, consultado só por_run_cgu_beneficios_cidadao._materialize_and_metadatapassa a receber esse valor nos doisupload_to_gcs, em vezde
"csv"fixo. Os outros três_run_cgu_*continuam no default"csv", que é o queeles gravam.
A causa:
partition_data_beneficios_cidadaograva parquet nonovo_bolsa_familia, e agarantia_safrausato_partitions(file_type="parquet"), mas osource_formatestavafixo em
"csv"para as três desde a migração para o Prefect 3. Isso era inofensivo atéa fix(br_bcb_sicor): destrava flows — poll por bytes tolerante + testes dbt #1677, que acrescentou
_sync_staging_schemano ramo em que a tabela de staging jáexiste — esse ramo chama
dump_header(source_format=...), que exige encontrar arquivono formato declarado. O
bpcnunca foi afetado, grava csv de fato.Mudanças nos dados e no schema: nenhuma. Os arquivos enviados são os mesmos; muda só
o formato declarado na criação e na checagem da tabela de staging.
_sync_staging_schemacompara nomes de coluna, então não altera tipo de nada.
Impacto no desempenho: nenhum.
Teste e Validações
Teste em https://prefect3.basedosdados.org/runs/flow-run/96747598-4dad-43bd-92a6-420c02a518fe
Summary by CodeRabbit
Bug Fixes
novo_bolsa_familiaandgarantia_safraare now uploaded in Parquet format.bpccontinues to be uploaded in CSV format.Documentation