feat: add set-schedule-active endpoint - admin_data_tools

[rdahis]

What

Adds POST /admin-tools/set-schedule-active/ — the API equivalent of ticking is_schedule_active in the Django admin.

Arming a flow schedule is currently only possible through the admin UI. There is no programmatic path, so tooling (the databasis MCP, scripts, CI) cannot arm or disarm a pipeline.

Why it can't just call Prefect

Arming is three writes, and DisabledFlowScheduleAdmin.save_model does all three:

1. is_schedule_active = True
2. reactivated_at = now()
3. Prefect3Client().set_paused(deployment_id, paused=False)

SyncDeploymentsView re-enforces the stored is_schedule_active state for known deployments, and CI POSTs it on every merge to main. So a caller that only unpaused via the Prefect API would appear to have armed the flow and then have it silently re-paused by the next unrelated merge. Keeping the three writes behind one endpoint is the point of this PR.

Design

• Bearer auth via the existing _check_bearer_token, same as the sibling endpoints, rejected before any write.
• Prefect before the database, mirroring the admin form — a Prefect failure leaves stored state untouched rather than recording a change that never reached the scheduler.
• Setting the current state is a no-op returning action="no_change" without calling Prefect. Mirrors the admin form (which only acts when the field changes), gives callers a safe way to read state, and doubles as a harmless auth probe.
• Unknown flow → 404 pointing at sync-deployments, which is what registers deployments in the first place.

POST /admin-tools/set-schedule-active/
{"flow_name": "<deployment name>", "is_schedule_active": true}

200 {"flow_name": ..., "deployment_id": ..., "is_schedule_active": true,
     "reactivated_at": "...", "action": "activated"|"disabled"|"no_change"}

Tests

The app had no tests. Adds 8, covering: arming, disarming, the no-op, a Prefect failure leaving stored state untouched, unknown flow, three malformed payloads, invalid JSON, and a bad token being rejected before any write.

Run locally against sqlite (no poetry env or Docker on this machine) — 8/8 pass. All pre-commit hooks pass.

Consumer

The databasis MCP gains set_deployment_schedule_active in basedosdados/mcp — it returns a 404 error dict until this ships, so merge this first.

[Winzen]

Conflito resolvido

main tinha dividido admin_data_tools/views.py em bigquery_sync.py/column_import.py/flow_monitoring.py enquanto este PR estava aberto. O merge do git detectou o rename e aplicou a SetScheduleActiveView corretamente dentro de flow_monitoring.py — só restou resolver manualmente o urls.py (imports + ordem das rotas). Push em bc14d38.

Bug achado durante a resolução (corrigido)

Os testes faziam @patch("backend.apps.admin_data_tools.views.Prefect3Client") — quebraria com ModuleNotFoundError já que views.py não existe mais com esse nome. Corrigido pra @patch("backend.apps.admin_data_tools.flow_monitoring.Prefect3Client"), que é onde a view de fato importa Prefect3Client agora.

Revisão — pontos de design pra discussão (não bloqueantes)

A lógica central está sólida e bem testada (8 casos, incluindo o de falha do Prefect). Dois pontos que valem conversa:

1. O caminho de no-op confia cegamente no banco, sem checar o Prefect. record.is_schedule_active == desired retorna no_change sem nenhuma chamada ao Prefect — mas se os dois já estiverem dessincronizados (exatamente o cenário de hoje: vários deployments do pipelines#1932 foram reativados via API direta do Prefect, sem passar por este endpoint, então o banco ainda diz is_schedule_active=False pra eles), chamar set-schedule-active com o valor que já "parece" ser o atual não corrige nada, mesmo com o Prefect no estado errado. Pode valer a pena o caminho de no-op confirmar contra o Prefect antes de decidir, ou pelo menos documentar essa limitação explicitamente pros consumidores (databasis MCP incluso).
2. Falha do Prefect vira um 500 cru, não um JSON de erro. Se client.set_paused lançar, a exceção sobe sem tratamento — o estado fica intacto (testado, correto), mas a resposta foge do padrão {"error": ...} usado nos outros casos (400/401/404). Um try/except com resposta JSON padronizada deixaria o contrato mais previsível pra quem consome.

Fora isso: bearer auth antes de qualquer escrita, ordem Prefect-antes-do-banco bem justificada no docstring, e o design do no-op como "auth probe seguro" é uma boa ideia.

[Winzen]

👌