Repository navigation
Import: give the job daemon a queue DSN its parser can read - #3057
Merged
Merged
Conversation
The detached production import requires its queue login to reach the database
with libpq verify-full TLS, so QUEUE_DATABASE_URL carries sslmode=verify-full and
a pinned sslrootcert. The importer started the Rust job daemon with that same
URL, which the daemon's tokio-postgres parser rejects ("transport refused:
unparseable DSN"). The existing tests use a loopback DSN, so they never hit it.
Under POLIS_JOBS_TRANSPORT=tls the daemon now gets the same postgresql:// URL with
only sslmode (verify-full or require) and sslrootcert removed, which the daemon
reproduces: built-in roots off, only the pinned CA trusted, hostname checked,
host restricted to an exact allowlist. Every other span is kept byte for byte,
and the derived DSN is never logged. Keyword/value DSNs and TLS policy
parameters the daemon does not reproduce (client certificates, CRLs, protocol
bounds and so on) are refused rather than dropped. The Python-side verify-full
requirement is unchanged.
Tests: Python unit tests on the exact production DSN shape, encoded keys, odd
passwords and the refusals, and a queue-rs test
that the derived DSN parses under TLS while the libpq form is refused. The
participant-facing request path is not touched.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018NVGBuYCk4EZmiz4csUv9s
Delphi Coverage Report
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Observable change: the detached production import can start its job daemon instead of failing immediately with "transport refused: unparseable DSN".
The import requires its queue login to use libpq verify-full TLS, so QUEUE_DATABASE_URL carries sslmode=verify-full and a pinned sslrootcert; the daemon parses DSNs with tokio-postgres, which rejects those parameters. Under POLIS_JOBS_TRANSPORT=tls the daemon now gets the same DSN with only the libpq TLS parameters removed; everything else is kept byte for byte and the derived DSN is never logged. The Python-side verify-full requirement is unchanged, and the daemon still verifies the server certificate (built-in roots off, only the pinned CA trusted, hostname checked, exact host allowlist).
Tests: Python unit tests on the exact production DSN shape; a queue-rs test that the derived DSN parses under TLS and the libpq form is refused. The participant-facing request path is not touched.
🤖 Generated with Claude Code