You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add notifications support for various lifecycle conditions
Co-authored-by: Thomas Countz <thomascountz@gmail.com>
Applications can configure any instrumentation backend that responds
to #instrument(event_name, payload), e.g. ActiveSupport::Notifications
Example:
ZendeskAPI.configure do |config|
config.instrumentation = ActiveSupport::Notifications
end
Events:
zendesk.request:
- When: All requests (emitted regardless of status code)
- Payload: duration (ms), endpoint, method, status
zendesk.rate_limit:
- When: Status < 500 AND rate limit headers present
- Not emitted for: 5xx errors, missing headers
- Payload: endpoint, status, remaining, limit, reset
- Note: Includes successful requests and 4xx errors when rate limit headers are present
zendesk.cache_hit:
- When: 304 Not Modified served from cache
- Requires: Cache enabled, matching ETag
- Payload: endpoint, status (304)
zendesk.cache_miss:
- When: 200 OK with ETag cached for future requests
- Requires: Cache enabled, ETag header present
- Payload: endpoint, status (200)
zendesk.retry:
- When: Before retry sleep (429, 503, or exception)
- Requires: Retry enabled; exceptions need retry_on_exception: true
- Payload: attempt (starts at 1), endpoint, method, delay (seconds), reason
- Reasons: "rate_limited" (429), "server_error" (503), "exception" (network failures)
Key assumptions/decisions:
- Users must supply their own compatible config.instrumentation, this lib does not pull in activesupport
- duration reports round-trip time including network call and response processing middleware
- Rate limit events only for status < 500 (client/rate limit errors)
- Request events emitted for all requests (not filtered by status)
- Instrumentation failures logged at debug level or silently swallowed
0 commit comments