chore(logging): add console logging when zyte API call fails

[jpetto]

• HNT-2442

Goal

log zyte api errors to the console as a first step to better address parse issues.

References

JIRA ticket:

• HNT-2442

[claude]

Claude finished @jpetto's task in 57s —— View job

---

PR Review

• Read CLAUDE.md for repo guidelines
• Read changed file and diff
• Analyze code and provide review feedback

---

Overall the intent here is solid — distinguishing HTTP-level failures from JSON parse failures gives much better signal for debugging Zyte issues. The changes are clean and the Sentry messages are more informative. One behavioral regression worth addressing before merge:

Critical: fetch() network errors are no longer caught

lib.ts:96 — The outer try/catch was removed, but the fetch() call itself is now unprotected. Any network-level failure (DNS resolution failure, connection refused, timeout, etc.) will throw an uncaught exception that propagates to the caller.

The original code's try/catch covered both the fetch and the JSON parse. The new code only has a try/catch around response.json(). The function's own JSDoc (line 85) still says:

"returns JSON from the metadata service, or an empty object on failure"

That contract is now only partially honored — it holds for HTTP errors and JSON parse errors, but not for network errors.

Suggested fix: wrap the fetch() call in its own try/catch (or wrap the whole block):

let response: Response;

try {
  response = await fetch(metadataParserEnpointUrl, { ... });
} catch (e) {
  Sentry.captureException(
    new Error(`Metadata parser network error for ${url}`),
  );
  console.error('Zyte network error:', { url, error: e });
  return res;
}

Fix this →

---

Minor: consider logging the error response body on HTTP failures

Right now console.error('Zyte API error:', { url, status, statusText }) is logged for non-OK responses. The Zyte API often returns a JSON body on errors (e.g. { "type": "...", "message": "..." }) that would make debugging much easier. Consider also reading and logging await response.text() (or .json()) on failure — carefully, since it can throw:

let errorBody: string | undefined;
try { errorBody = await response.text(); } catch (_) { /* ignore */ }

console.error('Zyte API error:', {
  url,
  status: response.status,
  statusText: response.statusText,
  body: errorBody,
});

This is a nice-to-have, not a blocker.

---

Everything else looks good — the separation of HTTP vs. JSON-parse error paths is a clear improvement and the console.error calls give the structured logging that the ticket is asking for.

[jpetto]

closed in favor of #404