Repository navigation
feat: vincula Table ao flow que a alimenta (Flow Schedule) - #1112
Merged
Merged
Conversation
Table ganha flow_schedule (FK pra DisabledFlowSchedule, related_name "tables") — vínculo automático entre uma tabela e o deployment que a alimenta, resolvido pelo sync-deployments. Resolução, em ordem: - Tag "<dataset_id>__<table_id>" do deployment (deploy_tags(), pipelines repo) ou o próprio nome, pra flows antigos que já seguem essa convenção direto. - Sem nenhuma dessas: nome menos o sufixo "_flow", tratado como dataset_id puro, vinculando todas as CloudTable daquele dataset de uma vez — cobre flow monolítico que alimenta várias tabelas num só deployment (confirmado contra produção: br_me_siconfi_flow, 7 tabelas). Uma tabela com flow dedicado nunca é roubada pelo fallback acima, mesmo que o flow monolítico seja processado primeiro no mesmo sync — a lista inteira de deployments é varrida uma vez antes de qualquer vínculo, pra achar que tabelas já têm dono específico. Admin: Table mostra o flow vinculado (label "Flow", clicável); DisabledFlowSchedule mostra as tabelas que alimenta. Testado de ponta a ponta contra Postgres real (Docker local): 22 testes passando. Backfill rodado contra produção real (leitura no Prefect, escrita só no banco local) confirmou os dois cenários reais que motivaram o design: br_me_siconfi_flow (7 tabelas) e uma tabela com flow dedicado dentro de um dataset multi-tabela.
Mostra o mesmo campo "Tables" já existente na listagem também na tela de edição individual, com cada tabela linkando pra sua própria página de admin. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Winzen
added a commit
that referenced
this pull request
Oct 7, 2026
A resolução de tabela por deployment (introduzida em #1112) fazia uma query de CloudTable por deployment. Com centenas de deployments isso multiplicou os round-trips ao banco o bastante pra estourar o timeout do gateway nginx em produção (POST /admin-tools/sync-deployments/ retornando 504 antes de terminar). Troca por um índice único, montado com uma query no início (_build_cloud_table_index), e troca o loop de save() por tabela por um update() em lote por deployment.
Winzen
added a commit
that referenced
this pull request
Oct 7, 2026
# Contexto Depois do merge de #1112, `POST /admin-tools/sync-deployments/` passou a estourar o timeout do gateway nginx (504) em produção, confirmado rodando contra prod via o token já usado por `set_deployment_schedule_active`. Causa: a resolução de tabela por deployment (`_resolve_single_table`) fazia uma query de `CloudTable` por deployment. Com centenas de deployments, isso multiplicou os round-trips ao banco o bastante pra passar do `proxy_read_timeout` do nginx — confirmado com duas tentativas reais, ambas cortadas em ~61s. # Mudança `backend/apps/admin_data_tools/flow_monitoring.py`: - `_build_cloud_table_index()`: carrega **todos** os `CloudTable` numa única query, indexados em dois dicts — `{(gcp_dataset_id, gcp_table_id): table_id}` pro match direto, `{gcp_dataset_id: {table_id, ...}}` pro fallback monolítico. - `_resolve_single_table_id`/`_dedicated_table_ids`/`_resolve_table_ids`: agora operam sobre esses dicts em memória (ids, não instâncias de `Table`) em vez de consultar o banco a cada chamada. - `_sync_deployment`: troca o loop `for table in tables: table.save()` por um único `Table.objects.filter(id__in=table_ids).exclude(...).update(flow_schedule_id=record.id)` por deployment. Resultado: 1 query de `CloudTable` pro sync inteiro (era N, uma por deployment), e 1 `UPDATE` em lote por deployment com tabelas vinculadas (era N `SELECT` + N `UPDATE`, um por tabela). # Benefícios - Sync volta a terminar dentro do timeout do gateway em produção. - Mesmo comportamento/contrato (`results` dict idêntico), sem mudança de schema. # Test plan 22 testes automatizados (os mesmos de #1112, incluindo os cenários de flow monolítico e exclusão de tabela dedicada) rodando verde contra Postgres real em Docker local, sem alteração nenhuma nos testes — a refatoração é transparente pro comportamento.
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexto
As tabelas não tinham nenhuma ligação direta com o flow/deployment do Prefect que as alimenta — último item pendente de
basedosdados/pipelines#2065.Registro completo, test plan e os dois cenários reais testados contra produção: #1111.
Arquivos alterados
Mudança
Table.flow_schedule(FK praDisabledFlowSchedule,related_name="tables"), resolvido emsync-deployments:dedicated_table_idsé calculado uma vez, olhando todos os deployments do sync antes de vincular qualquer um — garante que uma tabela com flow específico nunca seja "roubada" pelo fallback multi-tabela de outro deployment, independente da ordem em que o Prefect devolve a lista:Benefícios
Table.has_flow_scheduledá uma checagem rápida, sem denormalizar nada.br_me_siconfi_flow, 7 tabelas) sem quebrar quando uma tabela do mesmo dataset foge do padrão e vem de um flow dedicado — confirmado simulando esse cenário real contra produção, não só em teste.