[E2E] bug pipeline validation on gh-aw v0.77.5 (#34904 DIFC path)

[polmichel]

Summary

@me E2E validation of the bug-agent pipeline on gh-aw v0.77.5 (mcpg v0.3.22 / firewall 0.25.58), with min-integrity: approved forced on to exercise the DIFC proxy array-comments path from #34904.

Bug (for the pipeline to analyze)

The pagination helper truncates results when a caller passes limit=0. Expected: limit=0 means "no limit" (return all). Actual: it returns an empty list because the slice items[:limit] evaluates to items[:0].

Reproduce

1. Call the list endpoint with limit=0.
2. Observe zero items returned instead of all items.

Expected

limit=0 (or unset) returns the full collection; only a positive limit truncates.

---

This is an automated E2E test issue; safe to close after the pipeline run.

[polmichel]

/bug-analyze

[test-bug-pipeline]

✅ Bug analyst agent completed successfully!

[test-bug-pipeline]

Root cause analysis for #30

Issue: [E2E] bug pipeline validation on gh-aw v0.77.5 (#34904 DIFC path)
Based on: 5f9d0d692
Bug clarity: CLEAR
Code identification: RESOLVED

Root cause

The /search/docs endpoint truncates results with heading_results[:limit] whenever limit is not None, so an explicit limit=0 slices to [:0] and returns an empty list instead of the full collection.

Affected files

• backend/infrahub/api/internal.py -- line 176-177: the guard if limit is not None: admits limit=0, and heading_results[:limit] then becomes heading_results[:0] (empty). Endpoint defined at lines 163-190 (search_docs), signature limit: int | None = None.

Explanation

The handler is:

async def search_docs(
    query: str, limit: int | None = None, _: AccountSession = Depends(get_current_user)
) -> list[SearchResultAPI]:
    ...
    if limit is not None:
        heading_results = heading_results[:limit]

limit defaults to None (unset) and the intent is that only a positive limit should cap the number of results. The guard if limit is not None is too permissive: 0 is not None, so the branch executes and heading_results[:0] yields an empty list. The unset case (None) is handled correctly; only the explicit-zero case regresses. This exactly matches the report: limit=0 returns zero items instead of the full collection.

Note: the same flaw also affects negative values (e.g. limit=-1 would drop the last item via [:-1]), which is almost certainly unintended for a result cap.

Fix strategy

Approach: Narrow the truncation guard in search_docs so the slice is applied only for a positive limit. Treat both unset (None) and 0 as "no limit". The cleanest change is to make the condition require a positive value, e.g. gate the existing heading_results = heading_results[:limit] on limit is not None and limit > 0 (or equivalently if limit: combined with a positivity check). Reuse the existing slice; do not introduce new helpers.

Scope: One file, one function: backend/infrahub/api/internal.py, the search_docs handler (lines 176-177). A one- to two-line change to the conditional. No signature change, no new abstractions.

Do NOT:

• Do NOT change the parameter default or signature (limit: int | None = None is correct; the bug is the guard, not the default).
• Do NOT raise an error or special-case limit=0 as invalid input -- the spec says 0 means "return all".
• Do NOT introduce a new pagination utility/abstraction or refactor the result-building comprehension -- the fix is confined to the truncation condition.
• Do NOT use a bare if limit: without considering negatives if you want robustness; prefer an explicit positivity check (limit > 0) so negative values also fall through to "no limit" rather than slicing from the end.

Notes for downstream steps

• This is an HTTP route (GET /search/docs, include_in_schema=False) guarded by Depends(get_current_user); it relies on search_docs_loader (a module-level SearchDocs() that lazily loads JSON from disk). A unit test should avoid the auth dependency and disk loader -- prefer testing the truncation logic by calling the handler with a stubbed/patched search_docs_loader and a query/limit matrix, or by extracting/asserting the slice behavior directly.
• Test matrix to cover: limit=None (all), limit=0 (all -- the regression), limit=2 (first 2), limit greater than result count (all), and ideally a negative limit (should return all, not drop from the end).
• Empty query short-circuits to [] before the limit logic (line 167-168), so reproduction must pass a non-empty query that yields multiple heading results.
• Behavior for limit unset and limit=0 must be identical after the fix.

AGENT_ANALYSIS_COMPLETE

Generated by Bug analyst agent for issue #30 · opus48 602.1K · ◷
_{Comment /bug-analyze to run again}

[polmichel]

/bug-tdd

[test-bug-pipeline]

❌ Bug test-writer agent failed. Please review the logs for details.

[polmichel]

/bug-tdd

[test-bug-pipeline]

❌ Bug test-writer agent was cancelled. Please review the logs for details.