feat: accept request options on every method
Every SDK method now accepts per-request options with custom headers and an AbortSignal. Before, only create and send methods took them, so reads, updates and deletes could not be cancelled, timed out or traced. This completes the cancellation that #1072 started on writes.
Separate argument. The options are a last argument of their own, not fields in the params object, so they never mix with filters or pagination. Methods with an optional payload need undefined in that position.
Behavior change. Forwarding an inbound email now returns an error, not a rejected promise, when the raw download fails.
Not covered. Retries (#1108), a distinct abort error and the query cleanup come in follow-ups.
DEV-2177
Summary by cubic
Every SDK method now accepts per-request options with custom headers and an AbortSignal. Before, only create and send methods took them, so reads, updates, and deletes could not be cancelled, timed out, or traced. This completes the cancellation that #1072 started on writes.
Behavior change
- Forwarding an inbound email now returns an error, not a rejected promise, when the raw download fails or aborts.
- The options are a separate trailing argument, never mixed with filters or pagination; methods with an optional payload need
undefinedin that position. - A chained
publish()aftertemplates.createortemplates.duplicatesends its own request, so it takes its own options. - The options argument is named
requestOptionseverywhere for consistency; callers are unaffected.
Coverage
- One table-driven spec checks every public method forwards the header and the signal, and fails when a public method is missing from the table.
- Unused exported types
ListContactTopicsRequestOptions,UpdateContactTopicsRequestOptions,SendBroadcastRequestOptions, andCreateTemplateRequestOptionsare now reused by their methods.