Repository navigation
fix(import): word content-conversion errors accurately, not "PDF service" (#503) - #508
Conversation
…ice" (#503) importNode converts inline content at the write seam via hadrontool-pdf: text/html → /convert/html-to-markdown (#476), application/pdf → /convert/pdf-to-markdown (#488). Both surfaced failures as "PDF service error (N)", so a web-page clip that 404s (deployed tool predates the convert route, or PDF_SERVICE_URL misconfig) showed users a confusing "PDF service" message for a web page. Reword the two import/conversion paths to "Content conversion service …" while leaving renderMarkdownToPdf (actual markdown→PDF export) as "PDF service …". extensions.code values are kept stable (PDF_SERVICE_ERROR, PDF_SERVICE_UNREACHABLE, PDF_SERVICE_BAD_RESPONSE) so the Chrome extension's error handling is unaffected. Note: the P1 404 root cause is operational (redeploy/reconfigure hadrontool-pdf so the convert routes exist at PDF_SERVICE_URL) — this only clarifies the surfaced message. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the error messages in src/lib/pdfClient.ts to refer to the 'Content conversion service' instead of the 'PDF service' when performing HTML-to-markdown or PDF-to-markdown conversions. This prevents confusing users during web-page clipping or PDF imports. The module documentation and internal comments have also been updated to reflect this distinction. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Closes #503 (client-facing wording half; the prod unblock was a hadrontool-pdf redeploy — see below).
Problem
importNodeconverts inline content at the write seam via thehadrontool-pdfservice:text/html→/convert/html-to-markdown(importNode: convert captured HTML → Markdown via hadrontool-pdf /convert/html-to-markdown #476)application/pdf→/convert/pdf-to-markdown(importNode: accept application/pdf inline content (extract → Markdown node) #488)Both surfaced any non-2xx as
PDF service error (N). So a web-page clip that failed showed the user a "PDF service" error for a web page — confusing (#503).Change
Reword the two import/conversion paths (
convertHtmlToMarkdown,convertPdfToMarkdown) to "Content conversion service …" (error / unreachable / timed out / bad-response).renderMarkdownToPdf— the actual markdown→PDF export — keeps "PDF service …" wording, since that one really is PDF export. The module docstring now notes the client serves both directions.extensions.codevalues are left unchanged (PDF_SERVICE_ERROR,PDF_SERVICE_UNREACHABLE,PDF_SERVICE_BAD_RESPONSE,PDF_SERVICE_NOT_CONFIGURED) so the Chrome extension's programmatic error handling is unaffected — only the human-facing message string changes.Scope / context
This is the cosmetic half of #503. The actual P1 was operational: the deployed
hadrontool-pdfimage (0.0.1) predated the/convert/html-to-markdownroute, so web-page clips 404'd. That's been fixed out-of-band on alpha — the tool was rebuilt/redeployed (0.0.2), and the two Komodo config gaps that stopped the auto-deploy (missing GitHub build webhook +redeploy_on_build: false) were corrected. A CI gate was also added to hadrontool-pdf (hadron-memory/hadrontool-pdf#2).Test
tsc --noEmitclean.resolvers.importNode+resolvers.createUpdateNodesuites: 40 passed. No test asserted the old message strings.🤖 Generated with Claude Code