Skip to content

Derive the expected renderer policy from the platform in the render suite - #88

Merged
silverstein merged 1 commit into
masterfrom
claude/win-render-policy-fix
Aug 5, 2026
Merged

Derive the expected renderer policy from the platform in the render suite#88
silverstein merged 1 commit into
masterfrom
claude/win-render-policy-fix

Conversation

@silverstein

Copy link
Copy Markdown
Member

test/render-pdf-page.test.js hardcoded renderer_policy: "native_with_system_fallback". That value is macOS-only by construction: pdfjsRendererPolicy returns plain "native" whenever process.platform !== "darwin", because the system-renderer fallback is a macOS capability.

The product was behaving correctly. The assertion was wrong.

This is currently red on master

It is not Windows-specific. At unfixed master the same failure reproduces on Linux x64: 1 failed / 14 passed / 7 skipped, identical to the Windows runner. Any non-darwin host running this suite fails today. It stayed invisible because the aggregate release gate runs on macOS, where the hardcoded value happens to be right.

Evidence

  • Windows render proof at unfixed candidate (run 31051118605): 1 failed, exactly expected "native_with_system_fallback" / received "native".
  • Windows render proof at this commit (run 31051499142): success.
  • Linux x64 local, unfixed: 1 failed / 14 passed / 7 skipped. With this change: 15 passed / 7 skipped.

Scope

Test-only, one file. Product behavior unchanged. The expectation now derives from the platform, matching the idiom this suite already uses for its darwin-gated system-fallback block.

The two sibling occurrences of the same string (pdfjs-subprocess-boundary.test.js, pdfjs-worker-contract.test.js) pass the policy as an explicit input rather than asserting a platform-derived output, so they are correct as written and deliberately untouched.

🤖 Generated with Claude Code

…uite

test/render-pdf-page.test.js hardcoded renderer_policy as
"native_with_system_fallback". That value is macOS-only by construction:
pdfjsRendererPolicy (server/index.js) returns plain "native" whenever
process.platform !== "darwin", because the system-renderer fallback is a
macOS capability. The product was behaving correctly; the assertion was wrong.

The expectation is now derived from the platform, matching the idiom this
suite already uses for the darwin-gated system-fallback describe block. The
env-override paths (PDF_TOOLS_FORCE_SYSTEM_RENDERER / _DISABLE_) are not
mirrored here because this test runs in the default environment and those
routes have their own coverage.

Evidence:
- Windows runner (windows-render.yml at the v0.9.6 candidate, run
  31051118605): 1 failed / 14 passed / 7 skipped, the failure being exactly
  expected "native_with_system_fallback" / received "native".
- Reproduced identically on Linux x64 at unfixed origin/master: 1 failed /
  14 passed / 7 skipped, same assertion. So this was never Windows-specific.
- With this change, the suite is 15 passed / 7 skipped on Linux x64.

It stayed latent because the aggregate release gate runs on macOS, where the
hardcoded value happens to be correct. Any non-darwin host running this suite
fails on master today.

Scope: test-only, one file. Product behavior unchanged. The two sibling
occurrences of the same string (pdfjs-subprocess-boundary.test.js,
pdfjs-worker-contract.test.js) pass the policy as an explicit input rather
than asserting a platform-derived output, so they are correct as written and
are deliberately untouched.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@silverstein
silverstein merged commit 661cd0a into master Aug 5, 2026
1 check passed
silverstein added a commit that referenced this pull request Aug 6, 2026
Brings in the two test-only repairs landed 2026-08-06:
- PR #87 (6664f8e) order run-binding cleanup after fixture readiness
- PR #88 (9fbf6e4) derive the expected renderer policy from the platform

Delta is +24/-2 across test/eval/agent-workflow-run-binding.test.js and
test/render-pdf-page.test.js. No product, manifest, or dependency change.

Merged so the shipped head carries both fixes and the release aggregate binds
the tree that actually ships, rather than an ancestor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant