Skip to content

[MISC] Fix flaky integration CI: rig Postgres lock limit and unmocked pg_barrier dispatch - #2308

Merged
johnyrahul merged 1 commit into
mainfrom
misc/ci-rig-pg-locks-and-barrier-tests
Sep 30, 2026
Merged

johnyrahul merged 1 commit into
mainfrom
misc/ci-rig-pg-locks-and-barrier-tests

Conversation

@johnyrahul

Copy link
Copy Markdown
Contributor

What

  • Start the test rig's Postgres container with max_locks_per_transaction=256 (tests/rig/runtime.py).
  • Mock queue_backend.dispatch.dispatch in the 5 TestPgBarrierEnqueue tests that were really dispatching (workers/tests/test_pg_barrier.py), and drop a duplicated _barrier_pg_decrement import in the same file.

Why

The integration tier fails intermittently, in OSS and in every downstream cloud run, which tests against OSS main. Seen today on Zipstack/unstract-cloud main (a run failed at 11:21 and the same commit passed at 11:23) and on the v0.182.0 release PR (Zipstack/unstract-cloud#1808), which failed on its first run and again on a re-run.

  • Backend: out of shared memory / "increase max_locks_per_transaction". Every xdist worker migrates its own test database in one transaction, holding a lock per table and constraint. With the Postgres default of 64, the shared lock table overflows at random and errors the backend tests while their database is being set up: 704 errors on the first run, 47 on the re-run.
  • Workers: could not translate host name "unstract-db". UN-4078 (UN-4078 [MISC] Remove the Celery execution transport from the workers, backend and SDK #2284) made the PG queue the only transport, so PgBarrier.enqueue now really sends the headers. These 5 tests never mocked that, so it opened a connection from DB_* env (default host unstract-db) instead of the TEST_DB_* test database. The rest of the class already wraps enqueue in patch("queue_backend.dispatch.dispatch").

How

  • PostgresContainer("pgvector/pgvector:pg15").with_command("postgres -c max_locks_per_transaction=256").
  • The 5 tests now wrap enqueue in the same patch their neighbours use. Their assertions are unchanged; they check the barrier row, not the dispatch.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

  • No. Test-only: the rig's throwaway Postgres container and one test file. No product code, config or migrations are touched.

Database Migrations

  • None

Env Config

  • None

Relevant Docs

Related Issues or PRs

Dependencies Versions

  • None

Notes on Testing

  • Lock limit: started pgvector/pgvector:pg15 via testcontainers with the new command. SHOW max_locks_per_transaction returns 256 and the container passes its readiness wait. The effect on the flake can only be confirmed in CI.
  • pg_barrier: ran against a throwaway Postgres with the pg_barrier_state / pg_batch_dedup tables created by hand from the models, and DB_HOST unset, as in CI:
    • main's copy of the file: the same 5 tests fail with could not translate host name "unstract-db", matching CI.
    • This branch: TestPgBarrierEnqueue 10/10 passed; whole file 99 passed.
  • ruff check is clean on both files.
  • ruff format --check flags both files, but it flags main's copies identically, so that's pre-existing and not touched here.

Screenshots

Checklist

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

…ier enqueue tests

The integration tier fails intermittently for two unrelated reasons.

Backend: every xdist worker migrates its own test database in one
transaction, holding a lock per table and constraint. The rig's Postgres
runs with the default max_locks_per_transaction=64, so the shared lock
table overflows at random ("out of shared memory") and errors hundreds of
backend tests at setup. Start the container with 256.

Workers: five TestPgBarrierEnqueue tests never mocked
queue_backend.dispatch.dispatch. Since UN-4078 made the PG queue the only
transport, enqueue really dispatches the headers, opening a connection
from DB_* env (default host unstract-db) instead of the TEST_DB_* test
database. Wrap them in the same patch their neighbours use. Also drop a
duplicated _barrier_pg_decrement import.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@greptile-apps

greptile-apps Bot commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

via Greptile

RetriggerConfidence Score: 5/5

[Low risk] Test infrastructure and CI setup adjustments.

The PR appears safe to merge; no actionable regressions were identified.

Summary

This PR raises the integration rig’s Postgres lock limit and isolates five barrier-row tests from real queue dispatch. It also removes a duplicate import.

Reviews (1) · Last reviewed commit: "[MISC] Raise the rig Postgres lock limit..."

@github-actions

Copy link
Copy Markdown
Contributor

Unstract test results

Per-group results

Status Group Tier Passed Failed Errors Skipped Duration (s)
✅ e2e-api-deployment e2e 3 0 0 0 17.2
✅ e2e-coowners e2e 1 0 0 0 1.6
✅ e2e-etl e2e 1 0 0 0 8.5
✅ e2e-login e2e 2 0 0 0 1.6
✅ e2e-prompt-studio e2e 1 0 0 0 9.7
✅ e2e-smoke e2e 2 0 0 0 2.9
✅ e2e-workflow e2e 1 0 0 0 12.6
✅ frontend unit 620 0 0 0 19.1
✅ integration-backend integration 603 0 0 26 59.4
✅ integration-connectors integration 1 0 0 7 8.4
✅ integration-workers integration 164 0 0 1 40.4
❌ ui e2e 0 1 0 0 0.0
✅ unit-backend unit 1365 0 0 1 46.8
✅ unit-connectors unit 72 0 0 0 10.1
✅ unit-core unit 237 0 0 0 3.0
✅ unit-platform-service unit 15 0 0 0 2.8
✅ unit-rig unit 120 0 0 0 4.6
✅ unit-runner unit 10 0 0 0 3.0
✅ unit-sdk1 unit 718 0 0 0 29.9
✅ unit-workers unit 1383 0 0 1 121.1
TOTAL 5319 1 0 36 402.6

Critical paths

⚠️ Critical paths not yet covered

  • workflow-execution-fan-out — Multi-file workflow execution fans out to file-processing workers and rejoins. (declared coverage: no groups declared)
✅ Covered critical paths
  • auth-login — covered by e2e-login
  • adapter-register-llm — covered by integration-backend
  • workflow-author — covered by integration-backend
  • co-owner-manage — covered by integration-backend, e2e-coowners
  • workflow-create-execute — covered by e2e-workflow
  • api-deployment-provision — covered by integration-backend
  • api-deployment-auth — covered by integration-backend
  • api-deployment-run — covered by e2e-api-deployment
  • mcp-server-auth — covered by integration-backend
  • mcp-platform-auth — covered by integration-backend
  • platform-key-whoami — covered by integration-backend
  • prompt-studio-author — covered by integration-backend
  • prompt-studio-fetch-response — covered by e2e-prompt-studio
  • connector-register-test — covered by integration-backend
  • pipeline-etl-execute — covered by e2e-etl
  • usage-aggregate-read — covered by integration-backend
  • usage-token-tracking — covered by e2e-api-deployment
  • callback-result-delivery — covered by e2e-api-deployment

@johnyrahul
johnyrahul merged commit 9b76d92 into main Sep 30, 2026
14 checks passed
@johnyrahul
johnyrahul deleted the misc/ci-rig-pg-locks-and-barrier-tests branch September 30, 2026 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants