Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Bug: audit.sh orchestrator probe catch-all emits a hardcoded 'cannot reach repo' cause it never measured (stderr discarded)

Abierto
  • ¿Algo no está bien?
#65 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
bash
Área
cli, testing

Línea de trabajo

Start in audit.sh at the orchestrator-probe invocation and catch-all branch described in the issue; inspect how the probe's stderr is handled and how warn receives evidence. The issue includes a proposed stderr-capture change and an optional FW_ORCH_SCRIPT test seam. Validate that the failure evidence reports captured stderr or says the cause is undetermined, and that the probe's normal output remains suppressed.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Context

  • Framework version: 1.6.258
  • Project: 050-email-archive (shared-tooling mode)
  • Reported: 2026-09-25T00:44:09Z

Description

Summary

audit.sh's orchestrator-probe catch-all branch — the one reached only for exit codes the
author did not anticipate, i.e. the one place where the cause is by definition unknown — emits
a hardcoded Evidence line asserting the TermLink repo is unreachable. The only thing
actually measured on that path is the exit code.

Code (pre-fix)

bash "$ORCH_SCRIPT" >/dev/null 2>&1        # stderr discarded
ORCH_EXIT_CAPTURED=$?
...
else
    warn "Orchestrator-arc MCP scan: probe failed (exit $ORCH_EXIT_CAPTURED)" \
         "Cannot reach /opt/termlink via direct read or termlink interact" \
         "Check FW_TERMLINK_REPO and TermLink session availability"
fi

Two problems, and the first causes the second:

  1. The probe's stderr goes to /dev/null. The branch therefore has nothing to report and
    no way to know it has nothing.
  2. So it reports a guess — phrased with more certainty than any other line in the file.

Measured cost, not hypothetical

On 2026-09-25 this branch fired on our host with exit 126. Every clause of the emitted
evidence was false: the repo was reachable, termlink list --json worked, and the real cause
was E2BIG — the scan exported a 186,907-byte payload past Linux's
MAX_ARG_STRLEN (131,072) and execve failed before Python ran (filed separately as #63).

The consequence is the part worth acting on. This check is the ratchet that notices when a
gated MCP tool loses its check_task_governance. Following the stated mitigation
("Check FW_TERMLINK_REPO and TermLink session availability") leads the reader to two
healthy subsystems — so a dead safety defense read as a false alarm and was left alone. The
parallel framework-mcp leg printed [PASS] in the same section, which removed the last cue
that anything was wrong.

A blank evidence field invites investigation; a confidently wrong one ends it.

Fix applied downstream (please consider upstreaming)

-    bash "$ORCH_SCRIPT" >/dev/null 2>&1
+    ORCH_STDERR_FILE=$(mktemp -t orch-stderr-XXXXXX.log)
+    bash "$ORCH_SCRIPT" >/dev/null 2>"$ORCH_STDERR_FILE"
     ORCH_EXIT_CAPTURED=$?
@@
         else
+            ORCH_STDERR_TAIL=$(tail -3 "$ORCH_STDERR_FILE" 2>/dev/null | tr '\n' ';' | sed 's/;$//')
             warn "Orchestrator-arc MCP scan: probe failed (exit $ORCH_EXIT_CAPTURED)" \
-                 "Cannot reach /opt/termlink via direct read or termlink interact" \
-                 "Check FW_TERMLINK_REPO and TermLink session availability"
+                 "${ORCH_STDERR_TAIL:-cause not determined — probe exited $ORCH_EXIT_CAPTURED and wrote nothing to stderr}" \
+                 "Reproduce and read the failure directly: bash $ORCH_SCRIPT"
         fi
     fi
+    rm -f "$ORCH_STDERR_FILE"

stdout stays discarded (the scan prints a full report there); only the diagnostic channel is
kept. The fallback states that the cause was not determined rather than inventing one.

A scope limit we did NOT take, because it is your call

The obvious anti-recurrence rule — "no warn/fail evidence argument in a catch-all branch may
be a bare literal" — was implemented, run, and withdrawn. It flagged two legitimate
sites (audit.sh:4731 and :4736, whose headlines carry a measured value and whose evidence
explains the checked condition rather than claiming a new fact), and it would not have
caught this bug, whose headline also carried a measured value (exit $ORCH_EXIT_CAPTURED). The
real distinction is semantic — is this evidence asserting an unmeasured cause? — not
syntactic. Deciding which evidence literals are legitimate is a design call for the framework,
so we are reporting it rather than shipping a rule that produces false positives in your tree.

Untestable-by-construction (separate, smaller request)

We could not verify the corrected line renders correctly when the branch fires, because
ORCH_SCRIPT is hardcoded:

ORCH_SCRIPT="$FRAMEWORK_ROOT/agents/audit/orchestrator-mcp-scan.sh"

With #63 fixed, the probe no longer produces a non-0/1/2 exit, so the branch cannot be reached
without swapping the script on disk — not something to do on a shared host. A one-line seam
would make this branch testable:

ORCH_SCRIPT="${FW_ORCH_SCRIPT:-$FRAMEWORK_ROOT/agents/audit/orchestrator-mcp-scan.sh}"

A defensive branch that cannot be exercised is a branch that cannot be verified — which is
precisely the condition that let the false evidence above survive unnoticed.

Downstream references

Pen task T-2190 (finding X-05); companion filings #63 (E2BIG) and #64 (head -1 truncation
of the same check's warnings). All three are the same class: the audit's own output is not
itself audited.

Reported via fw upstream report from field installation

Lenguaje dominante
Shell
Estrellas
16
Forks
6
Merge medio
6 h 24 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DimitriGeelen/agentic-engineering-framework

Todos los issues de DimitriGeelen/agentic-engineering-framework

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.