[Feature] Detailed Error Report for Improved Debugging

[Junyi-99]

Problem

The current error tracing and reporting mechanism does not provide sufficient details about the root cause of errors.
In many cases, only high-level or generic messages (e.g. connection error, UNKNOWN rpc error) are shown, without actionable context.

As a result:

• It is difficult or impossible to locate the real source of failures

• Developers cannot reliably determine whether the issue is caused by:

  • network conditions
  • API changes
  • invalid parameters
  • internal state corruption
  • third-party dependencies

• Providing a proper fix or even a meaningful bug report becomes very hard

Current Behavior

• Errors are often logged as console.error with minimal messages

• Stack traces frequently point to bundled or minified code without:

  • original error type
  • error code mapping
  • request/response context
  • retry / timeout information

• Some errors are reported as Non-Error exceptions, losing semantic meaning

Expected / Proposed Improvement

Introduce a more detailed and structured error reporting system, for example:

• Preserve and expose:

  • original error type / class
  • error codes and their semantic meaning
  • full (unminified or symbolicated) stack traces when possible

• Include contextual metadata:

  • request endpoint / operation name
  • request parameters (sanitized)
  • response status / error payload
  • retry attempts, timeout, or cancellation info

• Clearly distinguish:

  • network errors
  • client-side logic errors
  • server-side errors
  • third-party service failures

This would significantly improve:

• Debuggability
• Issue triage efficiency
• The ability for contributors and users to propose accurate fixes

Motivation

Without detailed error reports, developers are effectively debugging blind.
Improving error visibility would greatly enhance developer experience and overall reliability of the project.