"Fix: PDF rendering timeout on page.goto with networkidle"

[vinsmokejazz]

Description

Fixes #799

Changes

• Changed wait_until="networkidle" to wait_until="domcontentloaded" in _render_page_to_pdf()
• Added explicit timeouts for each operation
• Wrapped font loading in try/except since fonts aren't critical for PDF rendering

Testing

• Tested resume PDF download successfully completes within 10-15 seconds
• PDF quality unchanged

---

Summary by cubic

Fixes PDF rendering timeouts by switching navigation wait to domcontentloaded and adding per-step timeouts, so resume PDFs generate reliably in ~10–15s.

• Bug Fixes
  • Use page.goto(..., wait_until="domcontentloaded", timeout=15000) to avoid hangs on networkidle.
  • Add explicit timeouts: selector wait 10s; font load 10s.
  • Wrap document.fonts.ready in try/except so font issues don’t block PDF rendering.

^{Written for commit a29f216. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

[Frankli9986]

Great fix! The domcontentloaded strategy is the right approach for static PDF rendering.

One suggestion: the bare except Exception: pass on document.fonts.ready silently swallows font loading failures, which makes production debugging difficult. Consider adding a logger.warning(...) so operators can see when fonts fail to load without blocking PDF generation.

Example:

try:
    await page.evaluate("document.fonts.ready", timeout=10000)
except Exception as e:
    logger.warning(f"Font loading failed for PDF generation (non-critical): {e}")

This is a small addition but significantly improves observability in production environments.

[vinsmokejazz]

Thanks for the review and the suggestion!

You're absolutely right, silently swallowing the exception reduces visibility into font-loading issues in production. Adding a non-blocking warning log is a good balance between reliability and observability