feature: add structured error logging in makeRequest catch block

[mohammedAgility]

Problem:
When makeRequest threw an exception, the existing error logging only output the error as a plain string (... ${error}). This made it difficult to diagnose the root cause of fetch failures — particularly in Node.js environments where the underlying network error is nested in error.cause.

Solution
Enhanced the catch block in makeRequest to log a structured error object that captures all relevant diagnostic properties, matching the detail needed to identify underlying network issues.

The following are now logged on every fetch exception:

name | TypeError | Top-level error type
message | fetch failed | Top-level error message
stack | (full trace) | Full stack trace
cause.name | ConnectTimeoutError | Underlying Node.js error type
cause.message | Connect Timeout | Underlying error message
cause.code | UND_ERR_CONNECT_TIMEOUT, ECONNRESET | Machine-readable error code

Changes
src/utils.ts - Added optional details field to the LogProps interface; updated logError to print it when present
src/api-client.ts - Updated catch block in makeRequest to pass structured error details to logError

Notes
Fully backwards compatible - details is optional on LogProps so no other logError call sites are affected
No behaviour change for non-error paths

[joelvarty]

We need to make this addition logging optional based on a env setting Yours, Joel Joel Varty CTO, Agility CMS 416-613-9676

…

________________________________ From: Mohammed Faisal Ansari ***@***.***> Sent: Tuesday, March 10, 2026 6:44:33 AM To: agility/agility-content-fetch-js-sdk ***@***.***> Cc: Subscribed ***@***.***> Subject: [agility/agility-content-fetch-js-sdk] feature: add structured error logging in makeRequest catch block (PR #128) Problem: When makeRequest threw an exception, the existing error logging only output the error as a plain string (... ${error}). This made it difficult to diagnose the root cause of fetch failures — particularly in Node.js environments where the underlying network error is nested in error.cause. Solution Enhanced the catch block in makeRequest to log a structured error object that captures all relevant diagnostic properties, matching the detail needed to identify underlying network issues. The following are now logged on every fetch exception: name | TypeError | Top-level error type message | fetch failed | Top-level error message stack | (full trace) | Full stack trace cause.name | ConnectTimeoutError | Underlying Node.js error type cause.message | Connect Timeout | Underlying error message cause.code | UND_ERR_CONNECT_TIMEOUT, ECONNRESET | Machine-readable error code Changes src/utils.ts - Added optional details field to the LogProps interface; updated logError to print it when present src/api-client.ts - Updated catch block in makeRequest to pass structured error details to logError Notes Fully backwards compatible - details is optional on LogProps so no other logError call sites are affected No behaviour change for non-error paths

________________________________ You can view, comment on, or merge this pull request online at: #128 Commit Summary * 714b403<714b403> feature: add structured error logging in makeRequest catch block File Changes (2 files<https://github.com/agility/agility-content-fetch-js-sdk/pull/128/files>) * M src/api-client.ts<https://github.com/agility/agility-content-fetch-js-sdk/pull/128/files#diff-42ff9f1380ec4f23f68cf329edd327ab3298a662fc2df90bd01da76a69fecf59> (17) * M src/utils.ts<https://github.com/agility/agility-content-fetch-js-sdk/pull/128/files#diff-39b2554fd18da165b59a6351b1aafff3714e2a80c1435f2de9706355b4d32351> (7) Patch Links: * https://github.com/agility/agility-content-fetch-js-sdk/pull/128.patch * https://github.com/agility/agility-content-fetch-js-sdk/pull/128.diff — Reply to this email directly, view it on GitHub<#128>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABCPVMOQHKNUO4HUND5HDRT4P7WZDAVCNFSM6AAAAACWM45X3OVHI2DSMVQWIX3LMV43ASLTON2WKOZUGA2TAOJRHEYDSMQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AaronAgility]

I closed this because it duplicates the efforts of something that was just merged and overwrites that new functionality. If you want to explore increasing the error exposure, please work from a stable main branch.