Skip to content

Route EscrowMonitor's swallowed handler/polling errors through SDKLogger with an onError hook #139

Description

@meshackyaro

Description

This issue aims to address the implementation of onError Hook for EscrowMonitor.

The core objective is to: Give EscrowMonitor (src/escrow/monitor.ts) a way to surface polling and handler errors — via the SDK's existing SDKLogger (src/utils/logger.ts) and an optional onError callback — instead of silently discarding them. EscrowMonitor.startPolling currently does const events = await fetchFn().catch(() => []) — any error from the caller-supplied fetchFn (e.g. a network failure fetching events) is silently swallowed and polling just continues with an empty event list, with no way for the consumer to know a poll failed. Handler errors are only slightly better surfaced: Promise.resolve(h(event)).catch(console.error) logs to raw console.error with no prefix/timestamp/structure, bypassing the SDK's own SDKLogger (currently unused anywhere per a companion issue) entirely, and gives the consumer no way to react.

By completing this feature, we will ensure that the TrustFlow protocol maintains its high standards for security, usability, and decentralized logic. This issue requires careful attention to the SDK Wrapper architecture and adherence to the existing project conventions.

Component

SDK

Difficulty

🟡 Medium

Tasks

  • Review existing Typescript classes (EscrowMonitor)
  • Implement SDK method for: an optional onError(error, context) callback on EscrowMonitor, invoked for both fetchFn failures and handler failures
  • Replace the raw console.error call with the SDK's logger (or make logging pluggable via the same mechanism)
  • Update typedoc comments for the new feature
  • Write Jest tests validating both the fetchFn-failure and handler-failure paths invoke onError

Acceptance Criteria

  • Feature accurately implements the objective above
  • Existing polling/handler behavior is unchanged for consumers that don't opt into onError
  • Any PR that introduces TypeScript errors is automatically blocked
  • Code is properly reviewed and approved by codeowners

Estimated Time

1-2 days

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions