Repository navigation
Pingora runtime policy scan decodes valid HWPX evidence as UTF-8 and blocks review #2116
Description
Failure and consumer impact
Private consumer ContextualWisdomLab/late-life-anxiety-reanalysis, PR #10 head 41a11ba6fcae431b4d22f29834cea39242cffdb1, fails the required OpenCode bootstrap before review:
Pingora edge policy could not establish complete evidence: Runtime policy candidate evidence/reviewer_response_draft.hwpx is not valid UTF-8
Actual check annotation: https://github.com/ContextualWisdomLab/late-life-anxiety-reanalysis/actions/runs/34696894954/job/103561804112 . Retrieved through GraphQL checkRun annotations on 2026-09-12; REST job logs were rate-limited, so no other failure is classified here.
The consumer HWPX passes unzip -t; its archive contains mimetype, version.xml, Contents/header.xml, Contents/section0.xml, and META-INF/manifest.xml. No document body, participant data, or private artifact is attached.
Root-cause candidate and owner
Read-only inspection of the canonical scripts/ci/pingora_edge_policy.py in the local .github checkout finds binary documentation handling for PDF/PNG, followed by strict UTF-8 decoding for other candidate formats. HWPX is a ZIP-based document and reaches that text path. The observed failure is consistent with this classification gap. The loaded workflow's exact source revision still needs confirmation before claiming a deployed root-cause fix.
Canonical owner: .github Pingora policy maintainers. Consumer tracking: late-life-anxiety-reanalysis PR #10 and issue #9. Existing related PDF/PNG handling should be reused; do not remove the document, suppress errors, or bypass actual runtime policy violations.
Next action and acceptance
- Confirm the failed run's loaded policy revision and reproduce the decoding failure with a minimal non-sensitive HWPX archive in the owner's existing tests.
- Validate HWPX as a binary document with magic/archive checks in the existing classification boundary, preserving strict validation of real policy/configuration inputs.
- Add focused tests for valid HWPX, malformed ZIP, and text renamed to
.hwpx; run the existing Pingora test suite. - Publish through the owner's coordinated PR and rerun exact-head consumer bootstrap/review. Local tests do not establish that the hosted check is repaired.
Internal investigation/review date: 2026-09-13, because this blocks mandatory review for a current manuscript PR. This is a next-action deadline, not a promise of deployment. No source modification or review bypass has been made in the consumer or central owner.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
seonghobae commentedon Sep 12, 2026
RCA reproduction completed against the reviewed canonical owner policy at local SHA
58e63c211a0199ca0d5d3f40794d4c460af0295b.A minimal synthetic HWPX ZIP containing
mimetypeandContents/content.hpfwas supplied through an in-memory Contents API opener to_load_file_content(). The stdlib-only path made no network/credential calls and raised:The binary-document classification currently recognizes PDF/PNG, and HWPX falls through to strict UTF-8 decoding. This confirms the defect on that owner source revision; the failed hosted run's loaded revision remains to be established. Existing owner untracked agent metadata was preserved. No source edit or hosted repair is claimed.
seonghobae commentedon Sep 12, 2026
Validated, unapplied owner candidate for #2116 at source baseline
58e63c211a0199ca0d5d3f40794d4c460af0295b.The supervisor reviewed and simplified the isolated patch, then ran:
New checks call the production
evaluate_pull_request: valid HWPX accepted; malformed bytes, truncated ZIP, wrong MIME and missing manifest rejected; harmless plaintext still scanned normally; runtime-policy text disguised as.hwpxstill producesnginx_runtime_path. Existing 67 owner regressions pass. The helper reads only the fixed HWPX MIME length plus one byte and does not decompress the manifest. Existing fallback policy scanning is reused without a duplicate branch.Patch SHA-256:
3467966cf0c0fb8e1ad51dc75ded02de01834e29dd1fb98966faaac6ff9dacb7. This is a local review candidate, not an applied owner change or hosted consumer fix. Please coordinate the canonical source writer, apply with focused tests, and revalidate the loaded release and exact consumer head before closing #2116.seonghobae commentedon Sep 12, 2026
Focused #2116 follow-up; this corrects the earlier candidate evidence and does not claim deployment.
34696894954resolved.github/workflows/opencode-review.yml@refs/heads/maintofb17ef556f94f673234aa557254ae52779e9a7b0in its immutable-source log. The policy step then exited 2 onevidence/reviewer_response_draft.hwpx. Current main has the same policy/test bytes as earlier local baseline58e63c211...._is_known_documentation_pathrecognizes only doc/docs/documentation. Adding.hwpxalone leavesevidence/reviewer_response_draft.hwpxon the failing UTF-8 path. The previous candidate also allows ZIP prefixes/trailers becauseZipFileaccepts them.1cb8cceb8719eb054979d84141cda9a95c0c6873: 106 passed withGITHUB_ACTIONS=true(84 existing + 22 new). No private document body was read or published for these tests.python3 -m pytest -q tests/test_pingora_edge_policy.py tests/test_pingora_hwpx_evidence.py; the fix(pingora): read Contents-API-oversized files through the Git Blobs API #1946 composition uses the same command prefixed byGITHUB_ACTIONS=true.e972b804824bdda9f56886503132c5c623883743; re-fetch before retry. Internal next review remains 2026-09-13.Format source: Hancom, “한/글 문서 파일 형식: HWPX 포맷 구조 살펴보기,” https://tech.hancom.com/hwpxformat/ (MIME marker and Contents/content.hpf package role).
Graphify 0.9.58 actually generated the two-file AST graph/report/HTML: 175 nodes, 253 edges. Explicit
extract --code-only --no-clusterandcluster-only --no-labelavoid the default labeler's unintended Claude invocation (the initial invocation failed its stop hook). This is local AST evidence only; no approved CO document-semantic extraction or hosted graph gate is claimed. Repeated callback names in inferred edges remain graph interpretation limits, not runtime proof.Combined source/test patch SHA-256:
1556073bc8e8ecaac5a4169e2c68a1fb4646a3b0560a3357239d0772154bd249.Coverage:
python3 -m coverage run --branch --source=scripts/ci -m pytest -q tests/test_pingora_edge_policy.py tests/test_pingora_hwpx_evidence.pythenpython3 -m coverage report -m: 388/388 statements and 174/174 branches, 100%. An initial incorrect--source=scripts/ci/pingora_edge_policy.pyselector emitted module-not-imported/no-data-collected; correcting the selector produced actual data with no warnings. No suppression was used.Full-repository collection exposed a test-packaging defect hidden by the minimal isolated corpus: the new test imported
test_pingora_edge_policywithout the repository'stests.package prefix. Corrected tofrom tests.test_pingora_edge_policy import policy, matching existing repository tests. The completeGITHUB_ACTIONS=true python3 -m pytest tests -qrerun passed: 3061 passed, 1 skipped, 36 subtests passed in 149.56 s. The one skip was independently identified with-rs:test_helper_admits_the_reviewed_llvm_19_tools_when_presentrequires reviewed LLVM 19 tools not installed on this host; that host-tool integration remains unverified. No warning/deprecation diagnostics appeared in the complete captured output. Previous 89/106 focused counts describe the earlier packaging revision; this full result covers the corrected package import.Full configured coverage gate on the corrected candidate also passed:
GITHUB_ACTIONS=true python3 -m coverage run -m pytest tests -q -rs→ 3061 passed, 1 skipped, 36 subtests passed;python3 -m coverage report -m→ 13,244 statements, zero missed; 5,356 branches, zero partial; 100%.python3 -m interrogate scripts/ci -qpassed the configured docstring gate. The same LLVM 19 host-tool skip remains; no warning/deprecation diagnostics appeared in the captured coverage run. These are isolated candidate results, not canonical adoption or consumer hosted success.Integration validation on the main tree with PR #1946 policy/test delta (
1cb8cceb8719eb054979d84141cda9a95c0c6873) plus the corrected HWPX candidate passed 3078 tests, 1 LLVM19 host-tool skip, 36 subtests. Configured coverage: 13,269 statements, zero missed; 5,368 branches, zero partial; 100%. No warning/deprecation diagnostics appeared in the captured full run. Separately, two additional cross-boundary regressions passed: a valid HWPX ZIP over 1 MiB at the exact consumer path follows Contents → Git Blobs and is admitted only when the returned blob SHA matches. This is combined local evidence, not a merged branch or hosted consumer success.Actual consumer artifact acceptance: fetched exact Git revision
a1cd5bc6783c6510dfcf937f523c733366e82213, bound the 19,821-byte HWPX to Git blobc576cc11b73531a11987e2cdd54cfe50a6f15d11(independently confirmed via GraphQL), and passed those bytes through the combined candidate productionevaluate_pull_requestusing an offline API fixture: zero violations, exit 0. This supersedes historical-head artifact observations; no private document contents are published or supplied to a model/graph. This proves actual-file local acceptance, not hosted workflow adoption.Unapplied source and executable pytest candidate
Additional PR1946-dependent HWPX blob integration regression
RED on main-based HWPX candidate without PR1946: 2 failed (size contract before blob retrieval). GREEN with PR1946: 2 passed. Keep this test with the combined implementation; it deliberately requires the blob retrieval dependency. AST-only graph refreshed for all four code files: 243 nodes; clustered graph SHA256
45e1b036f856b9a3db8c30ec1d88bc40c34b6c9c48515f96065d1972a4c31c26. Inferred same-name callback edges are not runtime proof.Save as
tests/test_hwpx_blob_integration.py:seonghobae commentedon Sep 13, 2026
The validated candidate above is now published as #2144 (branch
fix/pingora-hwpx-evidence-2116, head81a2cc61ae898974f8294a6e0c3c665857021ba9, based on mainfb17ef556f94f673234aa557254ae52779e9a7b0). It carries the main-based source +tests/test_pingora_hwpx_evidence.pyonly; the PR1946-dependent blob-integration regression is deliberately left out until #1946 lands.Branch evidence: RED 3 failed / 19 passed with only the test file applied; GREEN 90 passed across the three Pingora test modules;
pingora_edge_policy.pybranch coverage 100% (388 stmts, 174 branches); interrogate 100%; full suite 3061 passed, 1 pre-existing LLVM-19 host-tool skip, no warnings.Hosted acceptance remains: a newly loaded central SHA must re-run late-life-anxiety-reanalysis PR #10's exact head bootstrap. This issue stays open until that is observed.
seonghobae commentedon Sep 13, 2026
Re-verification status, 2026-09-13 09:10Z — not closing yet, consumer evidence is still missing for the HWPX condition specifically:
main: fix(pingora): admit bounded HWPX evidence documents without UTF-8 decoding #2144 merged at 04:38Z (64f483db9),tests/test_pingora_hwpx_evidence.pypresent.late-life-anxiety-reanalysisPR No UX changes required (No UI Codebase) #10, Required OpenCode Review run34748173771(08:38Z,WORKFLOW_SHA/TRUSTED_SOURCE_REF=64f483db9…). It still fails atEnforce Cloudflare Pingora edge policy, but on a different file:Runtime policy candidate evidence/manuscript_revision_pages/page_001.png is not valid UTF-8. The policy raises on the first non-admitted candidate, and that PNG path sorts beforeevidence/reviewer_response_draft.hwpx, so this run neither proves nor disproves the HWPX admission on the consumer head.Closure condition for this issue: a consumer run on a central
mainthat includes both #2144 and #2149's successor (or any run where the policy step passes/fails past the HWPX candidate) shows the HWPX file admitted. Until then the local RED→GREEN in #2144 is the only evidence.seonghobae commentedon Sep 14, 2026
Evidence separating the two conditions, 2026-09-14 05:2xZ (central
main@7f0702938, which contains #2144's64f483db9).A coordinator session for the consumer repo
late-life-anxiety-reanalysisreported being blocked on committing.hwpxreview evidence. That premise does not match the code onmain. Read-only probe ofscripts/ci/pingora_edge_policy.pyatorigin/main, calling_is_binary_documentation_assetdirectly withpatch_available=False:evidence/reviewer_response_draft.hwpxevidence/revised_manuscript.hwpxevidence/manuscript_revision_pages/page_001.pngdocs/evidence/page_001.pngSo #2144's admission rule (
pingora_edge_policy.py:235: suffix inBINARY_DOCUMENT_MAGICand (_is_known_documentation_pathor.hwpxwith anevidencepath part)) does admit HWPX underevidence/today. The PNG fails becauseDOCUMENTATION_DIRECTORIESis{doc, docs, documentation}(:52) andevidenceis not in it, so a PNG outside adocspath part gets no exemption and falls through to the UTF-8 content scan.This does not by itself close this issue — the stated closure condition is still a consumer run where the policy step reaches and admits the HWPX candidate, and the policy raises on the first non-admitted candidate (the PNG sorts first). It does mean the remaining work is entirely the PNG case in #2149, not the HWPX case here.
Consumer-side note for anyone blocked right now: a publication figure committed under a path containing
docs/(e.g.docs/evidence/manuscript_revision_pages/page_001.png) is admitted by the current rule with no central change. That is the policy's existing documentation-asset convention, not a suppression; the generalevidence/**/*.pngcase remains #2149's to land.seonghobae commentedon Sep 14, 2026
Progress toward this issue's stated closure condition: PR #2149 (the PNG lane that blocks the consumer run before it reaches the HWPX candidate) is restacked on current
mainat18f6baebdand verified — 110 passed intests/test_pingora_edge_policy.py/tests/test_pingora_hwpx_evidence.py, and the admission prefilter now returns True for bothevidence/manuscript_revision_pages/page_001.pngandevidence/reviewer_response_draft.hwpxwhile runtime forms (src/runtime/nginx.conf,evidence/startup.sh) stay blocked.Once #2149 merges, the consumer re-run on
late-life-anxiety-reanalysisPR #10 becomes the missing evidence this issue asks for: the policy step will pass the PNG candidate and reach the.hwpxone, which is the first run able to confirm or refute HWPX admission on a consumer head. The session coordinating that repository is standing by to re-run and report from the consumer side.🤖 Addressed by Claude Code
seonghobae commentedon Sep 14, 2026
Correction/extension to my previous comment — the
docs/path convention covers.pngand.pdfonly, not.svg. Verified againstorigin/main:docs/path part)_is_binary_documentation_asset_is_documentation_or_source_fixturedocs/figures/fig1.pngdocs/figures/fig1.pdfdocs/figures/fig1.svgBINARY_DOCUMENT_MAGICis{.hwpx, .pdf, .png}(:44-48) andDOCUMENT_SUFFIXESis{.md, .mdx, .rst, .adoc, .txt}(:34);.svgis in neither, so it receives no exemption anywhere.An SVG currently passes only incidentally:
_needs_content_scan(:645-661) returns False whenpatch_availableis true and the path matches no runtime rule, so a small SVG is never loaded. GitHub omitspatchfor very large text files too (this module's own comment at:437-443says so), and in that case the SVG is loaded; over the Contents API ceiling that raisesContentSizeExceededError, which is caught only inside_binary_documentation_evidence_confirms(:454) and only forgiven for.pdf(:455). A non-asset SVG never reaches that handler, so the error propagates and fails the check.Practical consequence:
.svgadmission is size-dependent and therefore unstable as a review-evidence format. Page renders should be committed as.pngor.pdf. This is adjacent to #2149's scope (that PR owns the generalevidence/**image case); recording it here so the constraint is in the repo rather than only in session messages.feat(pingora): admit declared research/data artifact paths (#2193) (#…
seonghobae commentedon Sep 17, 2026
Triage (2026-09-18): close-as-done candidate
Unique delta appears on protected
mainvia merged #2144 (bounded HWPX admission). Doctoring:docs/doctoring/pingora-hwpx-evidence-admission.md.Ranked backlog: #2251. Spot-check one consumer head with
evidence/*.hwpxbefore closing.seonghobae commentedon Sep 17, 2026
Closing after spot-check: unique valid delta is on protected
main.Merged fix: #2144 (merged 2026-09-13,
64f483db9d052322c65bcdf1675d66138156f306)Tree evidence on
origin/main:scripts/ci/pingora_edge_policy.pyadmits bounded.hwpx(BINARY_DOCUMENT_MAGIC,_is_complete_hwpx, evidence-path gate)docs/doctoring/pingora-hwpx-evidence-admission.mdpins the#2116incident and repairVerified with
git greponorigin/main(not redundancy alone).