GO — Healthy across all four use cases

• Last commit 4mo ago
• 37+ active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 4mo ago
• ⚠ Concentrated ownership — top contributor handles 56% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

asyncpg is a high-performance PostgreSQL client library for Python/asyncio that implements the PostgreSQL server binary protocol natively. It achieves ~5x faster query throughput than psycopg3 by exposing PostgreSQL features directly (prepared statements, scrollable cursors, custom type codecs) rather than hiding them behind a generic DB-API facade. Written in Cython and C for speed, it supports PostgreSQL 9.5–18 and Python 3.9+. Single-package structure: asyncpg/ is the main library. Core lives in asyncpg/protocol/ (coreproto.pyx, protocol.pxd) with codec handlers in asyncpg/protocol/codecs/ (.pyx files for arrays, ranges, records, custom types). Public API exposed via asyncpg/init.py; connection/pool/cursor logic in connection.py, pool.py, cursor.py. Tests and introspection tools in asyncpg/_testbase/ and asyncpg/introspection.py respectively.

Python developers building high-throughput async applications that need to query PostgreSQL efficiently—particularly data pipelines, web APIs built on asyncio frameworks (FastAPI, Starlette), and systems where database I/O is a bottleneck. Contributors are typically database library maintainers or performance-focused engineers working on asyncio infrastructure.

Production-ready and actively maintained. The project has substantial code maturity (706K lines of Python, 227K Cython, test suites in asyncpg/_testbase/), comprehensive CI via GitHub Actions (tests.yml, release.yml), and documented support for recent PostgreSQL versions (up to 18). Regular releases are managed via .github/release_log.py and RELEASING.rst.

Low risk for a mature library, but monitor these factors: (1) small core team (single maintainer risk implied by MagicStack/asyncpg naming pattern); (2) heavy reliance on Cython/C compilation (.pyx/.pxd files) means platform-specific build failures possible; (3) tight PostgreSQL version coupling—major PostgreSQL updates may require protocol-level changes. Dependency footprint is minimal (only sphinxcontrib-asyncio for docs), reducing supply-chain risk.

The repo is actively maintained with focus on compatibility (PostgreSQL 9.5–18 support, Python 3.9+ compatibility via asyncpg/_asyncio_compat.py) and performance optimization via Cython. GitHub Actions workflows run tests on commits. Release process is formalized (.github/release_log.py, RELEASING.rst). No specific major features visible from file structure, suggesting incremental refinement and bug fixes are the current focus.

git clone https://github.com/MagicStack/asyncpg.git
cd asyncpg
make  # builds Cython extensions; see Makefile for targets
pip install -e .  # editable install with compiled protocol extensions

(Requires PostgreSQL dev headers and a C compiler; see .github/workflows/install-postgres.sh for CI setup.)

Daily commands:

make clean
make  # builds Cython extensions (coreproto.pyx, protocol.pyx, etc.)
make test  # runs asyncpg._testbase test suite

For development: ensure PostgreSQL is running locally (or configure via DSN env vars); tests use asyncpg/cluster.py to auto-spawn test clusters. See .github/workflows/tests.yml for full CI matrix (Python 3.9–3.13, PostgreSQL 9.5–18).

• asyncpg/__init__.py — Main package entry point; exports the public API (connect, create_pool, exceptions, types).
• asyncpg/connection.py — Core Connection class managing PostgreSQL sessions and query execution; fundamental to all database operations.
• asyncpg/protocol/protocol.pyx — Cython-optimized PostgreSQL binary protocol implementation; handles wire-level communication and message parsing.
• asyncpg/pool.py — Connection pooling implementation for managing multiple concurrent database connections efficiently.
• asyncpg/protocol/codecs/base.pyx — Base codec infrastructure for encoding/decoding PostgreSQL data types between wire and Python objects.
• asyncpg/exceptions/__init__.py — Exception hierarchy mapping PostgreSQL error codes to Python exceptions for proper error handling.
• setup.py — Build configuration including Cython compilation of performance-critical protocol and codec modules.

• Connection (asyncio, Protocol, Codec) — Manages single PostgreSQL session lifecycle; queues SQL commands and returns decoded rows.
  • Failure mode: Network disconnect causes pending queries to raise ConnectionClosedError; automatic reconnection not built-in.
• Protocol (Cython) (Cython, asyncio socket) — Parses binary PostgreSQL protocol frames, dispatches ReadyForQuery/DataRow/Error/Notice messages.
  • Failure mode: Malformed wire data causes protocol violation; connection terminates; recovery requires new connection.
• Codec Registry (Cython, Python type objects) — Routes type OIDs to encoder/decoder pairs; handles built-in types and array/composite nesting.
  • Failure mode: Unknown type OID silently decodes as bytes; user must register custom codec or explicit type casting fails.
• Pool (asyncio.Queue, Connection) — Maintains queue of idle connections; distributes connections to acquire() calls with timeout and size limits.
  • Failure mode: Pool exhaustion causes acquire() to timeout; application must retry or fail gracefully.
• Transaction (asyncio, Connection) — Wraps BEGIN/COMMIT/ROLLBACK logic with savepoint nesting and async context manager interface.
  • Failure mode: Unhandled exception in async with block rolls back; nested savepoint on rollback does not restore pre-transaction state.
• Cursor (asyncio, Protocol, Codec) — Streams large result sets in batches without loading entire result into memory.
  • Failure mode: Long-running cursor holds connection; server-side cursor timeout may cause fetch() to fail.

• Application code → Connection.execute() — User submits SQL query string and parameters as tuple or list.
• Connection → Protocol (Cython) — Encodes parameters via Codec and formats Parse/Bind/Execute messages.
• Protocol → Socket (asyncio) — Writes binary wire protocol frames to PostgreSQL server; reads responses asynchronously.
• PostgreSQL server → Protocol — Sends DataRow frames containing column values and metadata; CommandComplete signals query end.
• Protocol → Codec (type dispatch) — Per-row decoding routes column bytes by OID to appropriate decoder function.
• Codec → Connection — Returns list of decoded Record objects or scalar values to caller.

Add a new PostgreSQL type codec

1. Create new .pyx file in asyncpg/protocol/codecs/ implementing Encoder and Decoder classes inheriting from BaseCodec. (asyncpg/protocol/codecs/mytype.pyx)
2. Register codec in asyncpg/protocol/codecs/init.py by importing and adding to codec registry with OID mapping. (asyncpg/protocol/codecs/__init__.py)
3. Add unit tests in tests/test_codecs.py covering encode/decode round-trips and edge cases. (tests/test_codecs.py)

Add a new Connection method

1. Define async method in asyncpg/connection.py with proper docstring and query parameter handling. (asyncpg/connection.py)
2. Export from asyncpg/init.py if it should be part of the public API. (asyncpg/__init__.py)
3. Add integration tests in tests/test_connect.py or create new test file following naming convention test_*.py. (tests/test_connect.py)

Add exception handling for a new PostgreSQL error

1. Add SQLSTATE code mapping in asyncpg/exceptions/init.py with custom exception class inheriting from appropriate base. (asyncpg/exceptions/__init__.py)
2. Test exception triggering and catching in tests/test_exceptions.py. (tests/test_exceptions.py)

Extend pool configuration

1. Add parameter to create_pool() function and PoolConnectionHolder class in asyncpg/pool.py. (asyncpg/pool.py)
2. Document the parameter in docstring and add integration test in tests/ covering pool behavior. (asyncpg/pool.py)

• Cython (protocol.pyx, codecs/*.pyx) — Compiles to C for high-speed binary protocol parsing and type encoding/decoding critical for performance at scale.
• asyncio — Native Python async/await integration for non-blocking I/O with PostgreSQL without threads.
• PostgreSQL binary protocol — Direct low-level wire protocol implementation avoids overhead of libpq wrapper for maximum throughput.
• Connection pooling — Reuses authenticated connections across requests to amortize handshake cost in high-concurrency scenarios.

• Pure asyncio without thread pool fallback

  • Why: Simpler design and lower overhead for I/O-bound workloads.
  • Consequence: CPU-bound operations block the event loop; applications must offload to ProcessPool or Executor.

• Cython-based protocol vs pure Python

  • Why: Achieves near-C performance for type encoding/decoding and protocol state machine.
  • Consequence: Requires C compiler and Cython toolchain; increases build complexity; harder to debug and contribute to protocol layer.

• Direct PostgreSQL protocol vs libpq wrapper

  • Why: Eliminates FFI overhead and allows fine-grained asyncio integration.
  • Consequence: Must maintain custom SCRAM and protocol parsing code; all PostgreSQL protocol changes require manual updates.

• Record object (C extension) instead of namedtuple/dict

  • Why: Faster column lookup and lower memory footprint for large result sets.
  • Consequence: Custom C extension maintenance burden; platform-specific compilation required.

• Does not support non-PostgreSQL databases or alternate database protocols.
• Does not provide ORM or query builder; users write raw SQL or use SQLAlchemy on top.
• Does not handle connection retry/failover; delegated to external orchestration or application logic.
• Does not expose synchronous API; asyncio is mandatory.
• Does not support older Python versions (requires 3.9+) or PostgreSQL < 9.5.

• Avg cyclomatic complexity: ~6.5 — Heavy Cython with manual C memory management, async state machines, and binary protocol parsing; protocol.pyx and codecs are high-complexity; pure Python layers (connection.py, pool.py) are moderate.
• Largest file: asyncpg/protocol/protocol.pyx (2,200 lines)
• Estimated quality issues: ~4 — Unbounded resource exhaustion (pool), silent type failures, lack of automatic reconnection, and manual C memory handling without bounds checking.

• Unbounded connection exhaustion in pool (High) — asyncpg/pool.py: Pool.acquire() can be starved if tasks hold connections indefinitely; no built-in connection timeout or idle eviction.
• Silent type coercion on unknown OIDs (Medium) — asyncpg/protocol/codecs/base.pyx: Missing codec for a type OID returns raw bytes instead of raising error; user discovers issue at runtime.
• No automatic reconnection on network failure (Medium) — asyncpg/connection.py: Connection.execute() raises immediately on socket error; application must manually retry or recreate connection.
• Blocking Record attribute lookup in hot path (Low) — asyncpg/protocol/record/recordobj.c: Column name caching in Record is not thread-safe if multiple threads access same Record concurrently.

• asyncpg/protocol/codecs/base.pyx (Algorithmic) — Type encoder dispatch uses linear search through codec map; scales O(n) with number of custom types.
• asyncpg/pool.py (Concurrency) — Pool.acquire() uses single lock for all connection distribution; contention point under high concurrency.
• asyncpg/protocol/protocol.pyx (Memory) — Protocol message buffer is copied on each recv_data() call; no zero-copy mmap or sendfile optimization.

1. Cython compilation required: make must succeed before import asyncpg works; missing PostgreSQL dev headers or C compiler causes silent import failures. 2. PostgreSQL must be running for tests; tests auto-spawn via asyncpg/cluster.py but require pg_ctl in PATH. 3. GSSAPI optional: special build flag for Kerberos support (see .github/workflows/install-krb5.sh). 4. Platform-specific bindings: protocol/ contains .pyx files with C++ interop (coreproto.pyx); platform inconsistencies possible (see .clangd, .clang-format for linting strictness). 5. Async context required: all public APIs are async/await—calling outside asyncio event loop fails immediately.

• PostgreSQL Binary Protocol — asyncpg's entire performance advantage comes from native implementation of PG's wire protocol (Frontend/Backend Message Format); understanding message framing, prepared statement cache, and type OID mapping is essential to debugging protocol-level issues
• Prepared Statements & Query Caching — asyncpg automatically caches prepared statements (prepared_stmt.pyx) server-side; critical for performance—developers need to understand statement lifetime, parameter binding, and cache invalidation to avoid resource leaks
• Codec System (Type Marshaling) — asyncpg's codec registry (protocol/codecs/) automatically encodes Python objects to PostgreSQL binary and decodes results back; extensible for custom types—understanding OID mapping, array/composite handling, and codec plugins is necessary for working with non-standard types
• Cython & C Interop — Performance-critical paths (protocol/coreproto.pyx, codecs) are written in Cython with C extensions; contributors must understand .pyx/.pxd file structure, GIL management, and cdef/cpdef declarations to modify low-level code
• Connection Pooling & Resource Management — asyncpg/pool.py implements a async-aware connection pool with initialization, health checks, and cleanup; critical for production apps—understanding acquire/release semantics, timeout handling, and graceful shutdown patterns is essential
• asyncio Event Loop & Backpressure — All I/O in asyncpg is multiplexed on a single asyncio event loop; understanding task scheduling, Future resolution, and backpressure handling in coreproto.pyx is needed to diagnose deadlocks or stalled queries
• SQLSTATE Exception Mapping — PostgreSQL errors are mapped to Python exception classes via SQLSTATE codes (asyncpg/exceptions/); understanding this mapping allows proper error handling and diagnosis of database-level failures (constraint violations, deadlocks, etc.)

• agronholm/sqlalchemy — SQLAlchemy ORM with asyncpg support; many asyncpg users integrate via sqlalchemy.ext.asyncio for higher-level query building
• encode/databases — Lightweight async database abstraction layer that wraps asyncpg (and others); alternative for users wanting DB-agnostic API over asyncpg's PostgreSQL-specific features
• psycopg/psycopg — psycopg3 is asyncpg's primary competitor; implements PostgreSQL protocol but is slower—useful for comparing design/performance trade-offs
• MagicStack/edgedb — EdgeDB uses asyncpg as its Python client underneath; demonstrates real-world async database layer built on top of asyncpg
• encode/starlette — Async web framework commonly paired with asyncpg for building high-performance REST APIs; natural ecosystem integration point

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive type hints and stub files (.pyi) for Cython modules in asyncpg/protocol/

The repo has partial type hints (protocol.pyi, record.pyi exist) but critical Cython modules like codecs/*.pyx, coreproto.pyx, scram.pyx, and settings.pyx lack corresponding .pyi stub files. This breaks IDE autocompletion and type checking for users. Adding complete stub files would improve DX significantly and allow mypy/pyright to properly type-check code using asyncpg.

• [ ] Analyze asyncpg/protocol/codecs/*.pyx (array.pyx, base.pyx, pgproto.pyx, range.pyx, record.pyx) to extract public API signatures
• [ ] Create corresponding .pyi stub files for each codec module with full type annotations
• [ ] Add .pyi stubs for asyncpg/protocol/coreproto.pyx, scram.pyx, and settings.pyx
• [ ] Test type checking with mypy/pyright on example code using these modules
• [ ] Update setup.py/pyproject.toml to include .pyi files in distribution (MANIFEST.in)

Add integration tests for PostgreSQL 15+ JSON path queries and enhanced features

The README states support for PostgreSQL up to version 18, but the test suite (located in asyncpg/_testbase/) likely lacks coverage for PostgreSQL 15+ specific features like JSON path expressions, MERGE statements, and native JSONB operators. Adding dedicated test modules would ensure these features work correctly and prevent regressions.

• [ ] Create asyncpg/_testbase/test_postgres_15_features.py for JSON path and MERGE statement tests
• [ ] Add asyncpg/_testbase/test_postgres_16_features.py for version 16+ specific functionality (e.g., RETURNING in DELETE/INSERT)
• [ ] Add asyncpg/_testbase/test_postgres_17_features.py for version 17+ features
• [ ] Update .github/workflows/tests.yml to run tests against PostgreSQL 15, 16, 17, and 18 versions
• [ ] Document expected behavior for each PostgreSQL version in docs/

Create asyncpg/protocol/codecs/json.pyx for optimized JSON encoding/decoding

Currently JSON handling is likely generic in the base codec system. PostgreSQL has native json/jsonb types with specific encoding requirements. Adding a dedicated JSON codec module (similar to array.pyx and range.pyx) would enable optimized serialization, custom JSON encoder configuration, and better performance for applications heavily using JSON columns.

• [ ] Create asyncpg/protocol/codecs/json.pyx with encode/decode functions for json and jsonb types
• [ ] Register JSON codec in asyncpg/protocol/codecs/init.py
• [ ] Add support for custom JSONEncoder/JSONDecoder configuration in connection parameters (asyncpg/connection.py)
• [ ] Add benchmarks in asyncpg/_testbase/ comparing current vs optimized JSON performance
• [ ] Add docstring examples to asyncpg/init.py showing custom JSON handling

• Add comprehensive docstring examples to asyncpg/cursor.py (currently minimal)—compare against connection.py examples and expand with real-world pagination + fetch patterns
• Extend asyncpg/_testbase/fuzzer.py with property-based tests for codec round-tripping (encode→decode) of edge-case PostgreSQL types (arrays of ranges, nested composites, custom types with NULL values)
• Write integration tests in asyncpg/_testbase/ for PostgreSQL 18 compatibility, particularly for newly deprecated protocol features—check PostgreSQL 18 release notes and add corresponding test cases

asyncpg demonstrates generally solid security practices with proper use of parameterized queries and async/await patterns. However, several areas require attention: (1) Cython/C extension modules handling untrusted protocol data need enhanced input validation and bounds checking, (2) Test certificate private keys should not be in version control, (3) Documentation should emphasize secure connection patterns. The codebase lacks explicit security hardening in build configuration and dependency management.

• Medium · Cython Extension Modules Without Input Validation — asyncpg/protocol/codecs/ (array.pyx, pgproto.pyx, range.pyx, record.pyx, base.pyx). The codebase contains multiple Cython (.pyx) files in asyncpg/protocol/codecs/ that handle PostgreSQL protocol parsing. These files (array.pyx, pgproto.pyx, range.pyx, record.pyx) process binary protocol data and perform type conversions. Without proper input validation in the Cython layer, malformed PostgreSQL server responses could lead to buffer overflows or type confusion attacks. Fix: Implement comprehensive input validation in Cython modules. Add bounds checking for all buffer operations. Use fuzzing tools (already present in asyncpg/_testbase/fuzzer.py) to test against malformed protocol messages. Consider adding assertion-based safety checks.
• Medium · Test Certificates with Exposed Private Keys — tests/certs/ (specifically ca.key.pem). Test SSL/TLS certificates are stored in the repository at tests/certs/ including private keys (ca.key.pem, client.cert.pem). While these are test certificates, storing private keys in version control is a security anti-pattern and could be accidentally used in non-test contexts. Fix: Move test certificates to a separate, non-versioned directory or generate them dynamically during test setup. Add tests/certs/ to .gitignore if not already present. Use fixtures that generate ephemeral test certificates.
• Medium · SQL Query Construction in Connection/Cursor Modules — asyncpg/connection.py, asyncpg/cursor.py, asyncpg/introspection.py. The asyncpg/connection.py and asyncpg/cursor.py files handle SQL execution. While asyncpg appears to properly use parameterized queries, the presence of raw query execution methods (execute, fetch, etc.) could be misused by developers. The introspection.py module may dynamically construct queries based on database metadata. Fix: Ensure all documentation clearly emphasizes parameterized query usage. Add type hints that encourage parameter binding. Review introspection.py for any dynamic SQL construction and validate/escape all database metadata before use.
• Low · C Extension Module Security — asyncpg/protocol/record/recordobj.c, asyncpg/protocol/record/recordobj.h. The codebase contains C source files (asyncpg/protocol/record/recordobj.c) implementing performance-critical record object functionality. C code requires careful memory management and can be vulnerable to buffer overflows if not properly validated. Fix: Enable compiler security flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2) in setup.py. Use AddressSanitizer and MemorySanitizer during testing. Keep dependencies on CPython API stable and review pythoncapi_compat.h for any unsafe patterns.
• Low · Missing Security Headers in Documentation — docs/conf.py, docs/usage.rst, docs/api/index.rst. The documentation (docs/conf.py) does not appear to include security-related configuration guidelines for users connecting to PostgreSQL, such as SSL/TLS enforcement recommendations or password handling best practices. Fix: Add security best practices section to documentation covering: mandatory SSL/TLS setup, connection pooling security, credential management (avoiding hardcoded passwords), and principle of least privilege for database users.
• Low · Dependency Version Pinning — pyproject.toml, setup.py, docs/requirements.txt. The setup.py and pyproject.toml files may not pin dependency versions for sphinxcontrib-asyncio and sphinx_rtd_theme. While these are documentation dependencies, unpinned versions could introduce vulnerabilities if a malicious or compromised version is released. Fix: Pin all dependencies to specific versions or version ranges. Use hash verification for critical dependencies. Regularly audit and update dependencies using tools like pip-audit or safety.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/MagicStack/asyncpg shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live MagicStack/asyncpg repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/MagicStack/asyncpg.

What it runs against: a local clone of MagicStack/asyncpg — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in MagicStack/asyncpg | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 150 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of MagicStack/asyncpg. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/MagicStack/asyncpg.git
#   cd asyncpg
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of MagicStack/asyncpg and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "MagicStack/asyncpg(\\.git)?\\b" \\
  && ok "origin remote is MagicStack/asyncpg" \\
  || miss "origin remote is not MagicStack/asyncpg (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "asyncpg/__init__.py" \\
  && ok "asyncpg/__init__.py" \\
  || miss "missing critical file: asyncpg/__init__.py"
test -f "asyncpg/connection.py" \\
  && ok "asyncpg/connection.py" \\
  || miss "missing critical file: asyncpg/connection.py"
test -f "asyncpg/protocol/protocol.pyx" \\
  && ok "asyncpg/protocol/protocol.pyx" \\
  || miss "missing critical file: asyncpg/protocol/protocol.pyx"
test -f "asyncpg/pool.py" \\
  && ok "asyncpg/pool.py" \\
  || miss "missing critical file: asyncpg/pool.py"
test -f "asyncpg/protocol/codecs/base.pyx" \\
  && ok "asyncpg/protocol/codecs/base.pyx" \\
  || miss "missing critical file: asyncpg/protocol/codecs/base.pyx"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 150 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~120d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/MagicStack/asyncpg"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.