fix: Retry flags requests on 502 and 504#209
Conversation
posthog-ruby Compliance ReportDate: 2026-07-02 12:22:20 UTC ✅ All Tests Passed!45/45 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 16/16 tests passed View Details
|
|
|
Addressed Greptile outside-diff comment from #209 (comment) in 5eefd01 by adding parameterized 502/504 coverage for feature_flag_request_max_retries = 3. The new examples assert 4 total requests (initial + 3 retries), the final exhausted response, and 3 backoff sleeps. Validation passed: |
💡 Motivation and Context
Remote
/flags/?v=2evaluations retried transient transport failures viafeature_flag_request_max_retries, but HTTP 502/504 responses were surfaced immediately. The SDK compliance harness expects/flagsto retry transient gateway responses while keeping retry behavior scoped to feature flag evaluation.This replaces the fork-based PR #208 with an equivalent branch pushed directly to
PostHog/posthog-ruby.💚 How did you test it?
Validation from the original branch:
ruby -c lib/posthog/feature_flags.rb→Syntax OKbundle exec rspec spec/posthog/flags_spec.rb→80 examples, 0 failuresbundle exec rubocop lib/posthog/feature_flags.rb spec/posthog/flags_spec.rb→2 files inspected, no offenses detected📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Implemented by an AI coding agent under human direction. The change keeps HTTP status-code retries scoped to the
/flagsremote evaluation request path and adds focused specs for 502/504 retry behavior, non-retry statuses, and max-retries opt-out. A changeset covers bothposthog-rubyandposthog-rails, since Rails consumes the Ruby SDK behavior.