bd.Table.create() só registra o ponteiro externo do BigQuery em basedosdados-staging, nunca em basedosdados-dev

[Winzen]

Resumo

bd.Table.create() (pacote basedosdados, usado por upload_to_gcs/pelo fluxo de materialização) registra a tabela externa do BigQuery — o "ponteiro" que permite fazer SELECT sobre os arquivos no GCS — sempre dentro de um projeto fixo, gcloud-projects.staging.name (~/.basedosdados/config.toml), que no ambiente real é basedosdados-staging. Não existe parâmetro em Table()/bucket_name/billing_project_id que mude esse destino.

O problema: a macro dbt set_datalake_project (macros/set_datalake_project.sql) resolve o projeto consultado de forma diferente por target:

target=dev  → basedosdados-dev
target=prod → basedosdados-staging

Ou seja, qualquer flow que rode dbt run/test com target=dev (como o mat_test_flow da #1867, que roda dev antes de prod) espera achar a tabela externa em basedosdados-dev — mas bd.Table.create() só a cria em basedosdados-staging. Sem uma segunda cópia manual do ponteiro em basedosdados-dev (mesmo schema, mesma config de particionamento Hive quando aplicável), o dbt run --target dev falha por tabela não encontrada.

Por que abrir agora

Achado durante o teste de ponta a ponta da #1867 (pipeline orientado a eventos) com um piloto novo (test_dataset.test_event_pipeline_partitioned). Foi o mais difícil de diagnosticar entre os problemas encontrados nesse teste: o piloto original (test_event_pipeline) já dependia dessa segunda cópia manual — criada em algum momento anterior da sessão, sem virar código nem documentação — então o gap ficou invisível até faltar de novo num piloto novo.

Qualquer dataset novo que siga esse fluxo (upload_to_gcs → dbt run --target dev) bate na mesma parede, sem aviso — o erro só aparece como "tabela não encontrada" em tempo de execução do dbt, sem apontar pra causa real.

Proposta

Duas alternativas, a decidir por quem tem mais contexto de por que a separação staging/dev existe:

1. upload_to_gcs/Table.create() (ou um wrapper em pipelines/utils/) passa a criar as duas cópias do ponteiro externo automaticamente (basedosdados-staging e basedosdados-dev), sempre que aplicável — inclusive replicando HivePartitioningOptions quando o dado é particionado.
2. Ou o pipeline deveria depender de só uma das duas cópias — revisitar por que a macro dbt resolve target=dev pra um projeto diferente de onde o dado é de fato registrado, e alinhar os dois.

Não decidido aqui qual caminho é o certo — abrindo pra registrar o gap e discutir.

Achado durante

#1867 (pipeline orientado a eventos), piloto test_event_pipeline_partitioned. PR #1932.