Skip to content

fix(reliability): bound DOCX page-layout unknown-field scans #341

Description

@seonghobae

Current active-PR truth

Draft PR #141 / branch feat/docx-page-layout remains the single writer for office/src/inkspan_office/page_layout.py, the public Office safety-facade integration, and the page-layout regressions. Protected shipped truth is main@3b38ead2d00f44eb578d0689087b9293b3dabe1e; current exact Draft head is aa5b10ff9a5b0c35f1840b881ca4f2c06707b636, already synchronized non-destructively with that protected tip. The prior issue snapshot at ad497ed4150d4648206afd65487bf0a8b3d14a40 is predecessor state and its checks/reviews do not transfer.

The original issue claim that validation scanned the complete caller Mapping and materialized set(mapping) is historical RCA. Current _reject_unknown() validates key type while scanning, rejects a repeated iterator key immediately, stops at the second distinct unknown field with the stable plural diagnostic, and emits the singular diagnostic only after a bounded complete scan with exactly one unknown. Because the allowed vocabularies are finite (three top-level keys / four margin keys), repeated keys fail immediately and two unknowns terminate the scan, so arbitrary caller metadata cannot force unbounded unknown-key enumeration.

The current branch also closes a later caller-interposition defect in the same public boundary: once the top-level page_layout value has been obtained from a host Mapping, the safety facade snapshots that value, validates the snapshot, and constructs the renderer payload without rereading the caller-owned page_layout member. This preserves the bounded unknown-field scanner and hostile-mapping redaction while preventing validation-to-use drift or a second getter/mapping access.

Test-first repair lineage

  • 4bd144047b9e573859097e29c17ae569b34a1817 bounded unknown-key scanning.
  • d1148b4980c689e1a1a0fb6e7dc092f17ac60225 added the repeated-iterator-key regression so exotic mappings cannot evade progress by repeatedly yielding an allowed key.
  • ad497ed4150d4648206afd65487bf0a8b3d14a40 added payload-redaction for hostile page-layout mapping failures.
  • Realistic RED c26e03fd2786019001ed1936538b631abc9b653d, CI 32577803247, Office Python 3.11 job 97042606441, proved a host Mapping whose validated page_layout value may be read only once was redundantly read by the public safety facade; the second access raised the test sentinel.
  • Current GREEN aa5b10ff9a5b0c35f1840b881ca4f2c06707b636 snapshots the top-level layout value once and reuses that validated snapshot without weakening unknown-key, type, range, hostile-reflection, determinism, or publication contracts.

Exact-current-head evidence

For unchanged aa5b10ff9a5b0c35f1840b881ca4f2c06707b636 against live main@3b38ead2d00f44eb578d0689087b9293b3dabe1e at the fresh pre-write refetch:

  • repository CI 32577971012: completed / success;
  • Security Scan 32577970957: completed / success;
  • SAST Semgrep 32577970975: completed / success;
  • Office Python 3.11–3.14 and cross-engine browser evidence are terminal success on that repository CI generation; the PR records 210 Office tests with exact 100% statement/branch coverage on Python 3.11 plus packed-package/demo/browser evidence;
  • formal reviews: one historical Cursor COMMENTED review, explicitly non-approving;
  • qualifying approving reviews: 0;
  • unresolved inline review threads: 0;
  • GitHub reports the Draft mechanically mergeable.

Repository exact-head success is technical evidence only. It does not establish any separately applicable central required workflow or qualifying independent approval. Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, or model-only evidence remains non-passing.

The technical defect is therefore repaired on the active Draft but is not protected-main shipped truth. Keep this issue open until #141 integrates under live governance. Do not create another page-layout writer, transfer predecessor evidence, or represent the active-PR repair as released behavior.

Integration boundary

#118 continues to own the frozen v0.6.0 publication/provenance boundary. #141 remains Draft/unmerged because qualifying independent approval is absent and the release boundary remains open. Any #141 head, protected-base, ruleset, review, or required-workflow movement requires fresh exact evidence before lifecycle action; never self-approve, weaken gates, force-push/destructively rebase, move protected main, or fabricate release identity.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dataDatabase, schema, migration, ETL, or lineagearea: securitySecurity boundary, hardening, or vulnerability preventionpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: bugDefect or incorrect behavior

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions