Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Check the Stage 12 database role's table privileges before each deploy

Aberta
#855 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
github-actions, postgresql, python
Domínio
ci-cd, database

Direção de pesquisa

Start by reading stage12-deploy.yml, simulation-deploy.reusable.yml, and rules/registry.toml, then inspect the persistence operations described for the two comparison-run tables. Trace the Stage 12 role's connection URL through each environment's secrets and the reusable workflow inputs. Done means the pre-deploy transaction checks each required operation, rolls back, and fails with the table and operation named when a permission is missing.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Problem

The simulation API and its Modal worker write the temporary comparison-run tables, stage12_evaluation_reports and stage12_evaluation_simulations, in the v2 Supabase database as policyengine_stage12_staging or policyengine_stage12_production, through libs/policyengine-stage12-persistence. Nothing in this repository checks, before a deploy, that the role can do what that code does.

The Public API had the same gap. In PolicyEngine/policyengine-api#3977, production's runtime role had no SELECT on a table one route read, and every reform save returned 503. CI ran as the database superuser, so no test could fail on it.

PolicyEngine/policyengine-api#3980 (PR PolicyEngine/policyengine-api#3985) now declares every managed role's table privileges in the Public API repository, in policyengine_api/data/v2/privileges.py. The Stage 12 role is declared to hold SELECT, INSERT, UPDATE and DELETE on the two comparison-run tables and nothing else. The Public API's deploy grants those privileges after each v2 schema upgrade and checks them. That deploy runs separately from this repository's stage12-deploy.yml, so a simulation API deploy can still start with a role that lacks a privilege its code needs: for example, when the persistence library starts a new kind of operation, or when grants are changed by hand.

Proposal

  1. A rule in rules/registry.toml, for example sim.stage12.role-privileges-checked-before-deploy: a deploy of the Stage 12 path doesn't start until the Stage 12 role has passed the check below.

  2. A check before the deploy steps in stage12-deploy.yml (or simulation-deploy.reusable.yml when deploy_stage12_v2 is true). It connects as the Stage 12 role and, in one transaction that is always rolled back, runs each operation policyengine-stage12-persistence performs on the two tables:

    • insert a report and a simulation with ON CONFLICT DO NOTHING ... RETURNING;
    • select them, including with FOR UPDATE;
    • update them.

    Any permission error fails the deploy and names the table and operation. No row survives the check.

  3. Proof: a role without UPDATE on stage12_evaluation_simulations fails the check; the declared role passes.

  4. Environment variables: name the secret that holds the Stage 12 role's connection URL for each environment, and confirm it reaches the new step (environment secrets:, reusable-workflow secrets: inherit, step env:).

Related

  • PolicyEngine/policyengine-api#3980 and PolicyEngine/policyengine-api#3985: declared privileges, the grant-and-verify deploy step, and integration tests that run the Public API's comparison-run services (policyengine_api/services/v2/comparison_runs) as policyengine_stage12_test.
  • PolicyEngine/policyengine-api#3977: the production incident.
Linguagem predominante
Python
Estrelas
1
Forks
1
Merge médio
1d 16h
PRs com merge (30d)
61

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de PolicyEngine/policyengine-sim-api

Todas as issues de PolicyEngine/policyengine-sim-api

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.