Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#65 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
bash
Lĩnh vực
cli, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Shell
Star
16
Fork
6
Merge trung bình
6 giờ 24 phút
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DimitriGeelen/agentic-engineering-framework

Tất cả issue của DimitriGeelen/agentic-engineering-framework

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.