Pré-existente (não vem da PR #27), levantado como hipótese na revisão adversarial dela e confirmado por execução.
O que acontece
WorkflowRunner.resume recebe project_id de quem chama e session_id da linha da run:
session_id = row["session_id"] if row["session_id"] is not None else session_id
O session_id é corrigido pela linha (conserto da Etapa 1, PR #16), mas o project_id não — ele continua sendo o que o CLI passou, que vem de --project. Como run --resume N --project <slug> exige --project e não confere se ele bate com a run, retomar apontando para outro project grava a generation no project errado.
Medido
Run criada no project alfa (id 1), retomada com project_id do beta (id 2):
run criada no project alfa: 1 (alfa=1)
generation: {'id': 1, 'project_id': 2, 'session_id': 1, 'run_id': 1}
sessão 1 pertence ao project 1
run continua apontando para project 1
A generation fica com project_id=2, enquanto a run e a sessão dela são do project 1. Nada reclama.
Por que importa
report --org e o custo por project somam generations.project_id. Uma generation atribuída a um project que nunca a rodou é custo de uma empresa aparecendo na conta de outra — exatamente o que o report toma o cuidado de não fazer quando se recusa a consolidar orgs diferentes num total só.
Conserto sugerido
O mesmo padrão que já vale para session_id: em resume, tirar project_id da linha da run, não do argumento. E, se --project divergir do project da run, recusar em vez de seguir — --project na retomada é redundante hoje, e redundância que pode discordar da fonte é um lugar onde o erro entra calado.
Pré-existente (não vem da PR #27), levantado como hipótese na revisão adversarial dela e confirmado por execução.
O que acontece
WorkflowRunner.resumerecebeproject_idde quem chama esession_idda linha da run:O
session_idé corrigido pela linha (conserto da Etapa 1, PR #16), mas oproject_idnão — ele continua sendo o que o CLI passou, que vem de--project. Comorun --resume N --project <slug>exige--projecte não confere se ele bate com a run, retomar apontando para outro project grava a generation no project errado.Medido
Run criada no project
alfa(id 1), retomada comproject_iddobeta(id 2):A generation fica com
project_id=2, enquanto a run e a sessão dela são do project 1. Nada reclama.Por que importa
report --orge o custo por project somamgenerations.project_id. Uma generation atribuída a um project que nunca a rodou é custo de uma empresa aparecendo na conta de outra — exatamente o que oreporttoma o cuidado de não fazer quando se recusa a consolidar orgs diferentes num total só.Conserto sugerido
O mesmo padrão que já vale para
session_id: emresume, tirarproject_idda linha da run, não do argumento. E, se--projectdivergir do project da run, recusar em vez de seguir —--projectna retomada é redundante hoje, e redundância que pode discordar da fonte é um lugar onde o erro entra calado.