Uh oh!
There was an error while loading. Please reload this page.
fix(fetchZyfiSponsored): enhance error handling and logging - #118
Merged
Conversation
Updated the fetchZyfiSponsored function to improve error handling by logging the response status and body when a fetch fails. This change provides clearer insights into the failure reasons. Additionally, adjusted the response parsing to use a single await for the response body, ensuring consistency in handling the response data.
LCOV of commit |
Douglasacost
enabled auto-merge (squash)
June 3, 2026 13:44
Move operation-tagged logging into fetchZyfiSponsored so all call sites (register, set-text-record, legacy index route) share the same format and error output includes HTTP status plus response body. Co-authored-by: Cursor <cursoragent@cursor.com>
aliXsed
approved these changes
Jul 8, 2026
Uh oh!
There was an error while loading. Please reload this page.
Douglasacost added a commit
that referenced
this pull request
Jul 30, 2026
Builds on #118, which added ZyFi status and body logging. Three gaps remain. 1. The global Express error middleware returns a 500 to the client but never logs, so no unexpected error on any route leaves a server-side trace. Log the message and stack for 500s, and log handled HttpErrors at warn level with method and URL. 2. `fetchZyfiSponsored` did not distinguish a network-level failure (DNS, TLS, connection reset) from an HTTP rejection. The request never reaches ZyFi in that case, so there is no status or body to report; say so explicitly. 3. `await response.json()` ran before the `response.ok` check, so a non-JSON error body — an HTML or empty response from a proxy or load balancer in front of ZyFi — threw a SyntaxError that discarded the status and left the same blind spot #118 set out to close. Read the body as text first, then parse, so the status survives a non-JSON response. Keeps the `operation` label convention introduced in #118.
aliXsed pushed a commit
that referenced
this pull request
Aug 5, 2026
…hs (#125) Builds on #118, which added ZyFi status and body logging. Three gaps remain. 1. The global Express error middleware returns a 500 to the client but never logs, so no unexpected error on any route leaves a server-side trace. Log the message and stack for 500s, and log handled HttpErrors at warn level with method and URL. 2. `fetchZyfiSponsored` did not distinguish a network-level failure (DNS, TLS, connection reset) from an HTTP rejection. The request never reaches ZyFi in that case, so there is no status or body to report; say so explicitly. 3. `await response.json()` ran before the `response.ok` check, so a non-JSON error body — an HTML or empty response from a proxy or load balancer in front of ZyFi — threw a SyntaxError that discarded the status and left the same blind spot #118 set out to close. Read the body as text first, then parse, so the status survives a non-JSON response. Keeps the `operation` label convention introduced in #118.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Centralizes ZyFi paymaster logging in
fetchZyfiSponsoredso every call site shares the same format.logZyFi request [operation]: …logZyFi response [operation]: …errorZyFi error [operation] {status} {statusText}: …Call sites pass an operation label (
register,set-text-record) instead of duplicating log statements. The legacy register route inindex.tsis included for consistency.Errors throw with the operation name and API message (or serialized body) for easier tracing in request logs.
Test plan
[register][set-text-record]