Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#855 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, postgresql, python
Área
ci-cd, database

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
1
Forks
1
Merge medio
1 d 16 h
PR fusionados (30 d)
61

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/policyengine-sim-api

Todos los issues de PolicyEngine/policyengine-sim-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.