We must implement open-feature/flagd#2027, which changed the spec defaults so the stream-reconnect backoff can't leave us disconnected longer than the stale grace period.
providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/Config.java:20 DEFAULT_MAX_RETRY_BACKOFF_MS: 12000 -> 5000providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/Config.java:22 DEFAULT_STREAM_RETRY_GRACE_PERIOD: 5 -> 10
providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/resolver/common/ChannelBuilder.java:57 also sets maxAttempts to 3, but the spec's retry policy specifies 4 (the initial attempt plus retries at 1s, 2s, 4s); should be 3 -> 4. Harmless to fix now since nothing clamps at a 5000 cap.
Unlike the Go provider (open-feature/go-sdk-contrib#936), Java already implements streamDeadlineMs, keepAliveTime, and offlinePollMs, so no missing options here.
With 5000/10 a deadline-driven recycle reconnects well inside the grace period, yielding a STALE/READY pair and no ERROR. We should also pick up the updated testbed ready -> stale -> ready scenario (open-feature/flagd-testbed#386), which now asserts no ERROR event fires, and implement the new the error event handler should not have been executed step.
Blocked on flagd#2027.
Related
We must implement open-feature/flagd#2027, which changed the spec defaults so the stream-reconnect backoff can't leave us disconnected longer than the stale grace period.
providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/Config.java:20DEFAULT_MAX_RETRY_BACKOFF_MS: 12000 -> 5000providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/Config.java:22DEFAULT_STREAM_RETRY_GRACE_PERIOD: 5 -> 10providers/flagd/src/main/java/dev/openfeature/contrib/providers/flagd/resolver/common/ChannelBuilder.java:57also setsmaxAttemptsto 3, but the spec's retry policy specifies 4 (the initial attempt plus retries at 1s, 2s, 4s); should be 3 -> 4. Harmless to fix now since nothing clamps at a 5000 cap.Unlike the Go provider (open-feature/go-sdk-contrib#936), Java already implements
streamDeadlineMs,keepAliveTime, andofflinePollMs, so no missing options here.With 5000/10 a deadline-driven recycle reconnects well inside the grace period, yielding a STALE/READY pair and no ERROR. We should also pick up the updated testbed
ready -> stale -> readyscenario (open-feature/flagd-testbed#386), which now asserts no ERROR event fires, and implement the newthe error event handler should not have been executedstep.Blocked on flagd#2027.
Related
retryGracePeriodandretryBackoffMaxMsare pathological flagd#2027 (parent)