WORKED EVIDENCE / SELF-MAINTAINING APIs

A repair that review changed

A provider upgrade broke an authored reporting application. Review then found a connection-lifetime defect that correct-looking rows could conceal.

Test setting: pandas 1.5.3, SQLAlchemy 1.4.46 and 2.0.0, and SQLite. The library incompatibility was real. The application, requirements and checks were authored for this investigation.

Problem, finding and correction

QuestionFirst candidateReviewed correction
What did the code do?Return a chunk iterator from inside a connection context.Yield chunks while still inside the connection context.
Why did the first result look acceptable?SQLite could still return the expected rows after the context ended.The test also examined ownership while the consumer was still iterating.
What did C01 observe?0 checked-out connections while iteration was in progress. The requirement was 1. FAIL.Connection retained during iteration and released on exhaustion. PASS.
What else did review check?3 of 4 additional challenges passed.4 of 4 passed, covering lifetime, early close, error cleanup and parameters.

The primary comparison

These twelve checks examined selected query behavior, write persistence, rollback and cleanup. They are a different test set from the four additional challenges below.

Engineering conditionSelected primary checks passed
Original application / old stack11 / 12
Provider upgrade alone1 / 12
First application repair11 / 12
Ordinary pandas upgrade11 / 12
Revised repair / upgraded provider12 / 12
Revised repair / old stack12 / 12

The original stack already had a rollback defect. That failure predates the provider upgrade. The ordinary pandas upgrade remains visible as a simpler engineering alternative.

The additional review challenges

ChallengeFirst candidateRevised candidate
C01: Connection retained during iterationFAILPASS
C02: Explicit early close returns connectionPASSPASS
C03: Error propagates and connection returnsPASSPASS
C04: Parameters remain data; table unchangedPASSPASS

The retained observations

These are selected fields from the retained test records, not newly generated test results. We omit traceback paths and unrelated execution metadata.

C01 before correction

{
  "id": "C01",
  "status": "FAIL",
  "error_type": "AssertionError",
  "error": "('iterator outlived its connection', 'Pool size: 1  Connections in pool: 1 Current Overflow: 0 Current Checked out connections: 0')"
}

C01 after correction

{
  "id": "C01",
  "status": "PASS",
  "observation": "Connection retained during iteration and released on exhaustion"
}

The test required one checked-out connection while iteration was still in progress. The first candidate reported zero. The core assertion, with formatting normalized from the retained traceback, was:

assert e.pool.checkedout() == 1

Download the selected before/after records for all four challenges.

The ownership change in Python

The schematic below illustrates the connection-lifetime change described in the study. It is not the original executed source, a complete patch, or proprietary HSDLG code. The helper read_chunks stands for the selected chunked query path.

Defective ownership patternRevised ownership pattern
with engine.connect() as connection: return read_chunks(connection, statement, params)with engine.connect() as connection: yield from read_chunks(connection, statement, params)

Returning the iterator lets the function exit the connection context immediately. Yielding inside the context keeps it active while consumption continues. The additional checks covered exhaustion, explicit early close and errors. The full study explains the surrounding transaction and query-handling boundaries.

What HSDLG and the assistant supplied

The assistant interpreted the library change and wrote the repair. HSDLG’s documented review methods structured the challenges and correction. Selected local HSDLG controls supplied bounded execution, retained records and replay/accounting behavior. The study did not isolate their causal contributions.

The correction kept connection ownership aligned with consumption: the generator yielded chunks inside the connection context until exhaustion, explicit close or error. This is a public explanation of the repair mechanism, not disclosure of proprietary HSDLG implementation.

What this establishes

The retained records show a specific defect, a corresponding implementation correction, and passing results for the selected checks. This is one known transition, with exposed tests and same-assistant production and review. It does not establish a general repair success rate, independent efficacy, unattended maintenance or a fully qualified MCP platform.

Inspect the supporting work

Source basis: retained summary.json, challenges_v1.json and challenges_v2.json, as summarized in the API evidence study. No experiments were rerun for this presentation update. Further technical documentation, standards and test records are available for scoped diligence under an appropriate NDA or contract.