Ruby provider: HTTP timeouts are not configurable (Net::HTTP 60s defaults apply)

Aperta
  • Qualcosa non va?
#652 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@reginaldalfret ci sta già lavorando.

Dal 28/10/2026.

  • #668 di @reginaldalfret — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ruby
Ambito
backend

Direzione di ricerca

Start by locating the Ruby provider's APIClient#initialize and private build_agent, then inspect the existing APIError handling and README. The issue proposes configurable timeouts, timeout-error wrapping, validation, and documentation, but leaves the API shape and default behavior unresolved. Done means those decisions are settled and the options and error behavior are implemented and documented.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

The Ruby OpenFeature provider (confidence-openfeature-provider, 0.2.0) has no way to configure HTTP timeouts. It is an online resolver that makes a HTTP call for every flag evaluation.

Current behavior

  • APIClient#initialize(client_secret:, region:, events_uri:) takes no timeout options.
  • The private APIClient#build_agent creates a fresh Net::HTTP for each request and sets only use_ssl. Ruby's defaults therefore apply: open_timeout 60s, read_timeout 60s and write_timeout 60s.
  • The events API (track) goes through the same build_agent, so the same applies there.
  • When a timeout fires, Net::OpenTimeout or Net::ReadTimeout is raised unwrapped, unlike HTTP-status and JSON errors, which are wrapped as APIError.
  • The only workarounds are overriding the private build_agent in a subclass, which is fragile, or wrapping calls in Timeout.timeout, which is unsafe.

Why it matters

Flags are often resolved inline in request handlers. Our case: A degraded Confidence API can stall sign-up requests for minutes and tie up web threads. We'd like roughly a 1s connect and 1s read limit, so that the worst case adds about 2s.

Prior art

The Java remote-resolver SDK already exposes this (README):

Confidence.builder("<CLIENT_SECRET>")
    .resolveDeadlineMs(250)       // default 10_000
    .eventSenderDeadlineMs(...)   // default 5_000

Proposed solution

  1. Add optional timeout keyword arguments to APIClient.new, either per phase (open_timeout:, read_timeout:, write_timeout:) or per endpoint like Java (resolve_timeout:, events_timeout:). Existing APIClient.new(client_secret:, region:) calls keep working.
  2. Apply them to each Net::HTTP agent in build_agent, keeping the one-agent-per-request design.
  3. Wrap Net::OpenTimeout, Net::ReadTimeout and Net::WriteTimeout in APIError, keeping the original as cause. Evaluations then return the default value with reason ERROR, track still never raises, and track! raises APIError.
  4. Reject negative or non-numeric values with ArgumentError.
  5. Document the options and defaults in the README.

Note that Net::HTTP has no total-deadline option the way gRPC does, so the bound is per phase: connect plus read, not one overall limit.

Open questions

  • Defaults: match Java (10s for resolve, 5s for events) for consistency, or use something lower such as 2s, since the Ruby provider always resolves over the network? Is lowering from 60s acceptable as a non-breaking change, or should the default stay as Net::HTTP's and only become configurable?
  • API shape: per-phase options (closest to Net::HTTP), per-endpoint options (closest to Java), or both?
  • Wrapping other transport errors: should errors such as ECONNREFUSED and SocketError also be wrapped as APIError for consistency?
Lingua principale
Rust
Stelle
17
Fork
18
Merge medio
1h 25m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spotify/confidence-resolver

Tutte le issue di spotify/confidence-resolver

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.