FlagdProvider default keep_alive_time=0 causes GOAWAY crash with flagd server
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- backend, networking
Hướng nghiên cứu
Bắt đầu trong config.py tại DEFAULT_KEEP_ALIVE và trong grpc.py tại _generate_channel(), sau đó kiểm tra cách cả hai kiểu resolver IN_PROCESS và RPC xây dựng channel của chúng. Chọn xem có nên tăng giá trị mặc định hay bỏ qua tùy chọn keepalive khi giá trị bằng không. Hoàn tất khi giá trị mặc định không còn gây ra các ping ngay lập tức, GOAWAY hoặc sự cố ARM đã được báo cáo.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description
The FlagdProvider defaults keep_alive_time to 0 (DEFAULT_KEEP_ALIVE = 0 in config.py), which is passed directly to grpc.keepalive_time_ms as a channel option.
In the Python gRPC C-core implementation, keepalive_time_ms=0 is interpreted as "send pings immediately / every ~1ms" rather than "disabled". This causes flagd's Go gRPC server to reject the connection with:
GOAWAY [ENHANCE_YOUR_CALM] "too_many_pings"
flagd's Go gRPC server uses the default grpc-go enforcement policy with MinPingInterval=5min. Any keepalive interval below 5 minutes triggers the GOAWAY.
Impact
- On aarch64/ARM (e.g., Raspberry Pi), the GOAWAY triggers a fatal gRPC C-core assertion failure in
ev_epoll1_linux.cc:Check failed: next_worker->state == KICKED— crashing the entire Python process - On x86_64, the client typically reconnects but logs repeated GOAWAY warnings, degrading performance and reliability
This affects both the IN_PROCESS and RPC resolver types since both create gRPC channels with the same keepalive options.
Reproduction
from openfeature.contrib.provider.flagd import FlagdProvider
from openfeature.contrib.provider.flagd.config import ResolverType
# Default keep_alive_time=0 → immediate crash/GOAWAY with flagd server
provider = FlagdProvider(
host="flagd",
port=8015,
resolver_type=ResolverType.IN_PROCESS,
)
flagd server logs:
Received a GOAWAY with error code ENHANCE_YOUR_CALM and debug data equal to "too_many_pings"
Client crash (ARM only):
F0000 00:00:1773608949.106482 38 ev_epoll1_linux.cc:1125] Check failed: next_worker->state == KICKED
Suggested Fix
Change the default from 0 to a value that respects flagd's server-side MinPingInterval of 5 minutes:
# config.py
DEFAULT_KEEP_ALIVE = 600000 # 10 minutes (ms) — above flagd's 5min MinPingInterval
Or alternatively, don't set grpc.keepalive_time_ms at all when keep_alive_time=0, letting the gRPC library use its own default (which is "infinite" / disabled in the C-core):
# grpc.py - _generate_channel()
options = []
if config.keep_alive_time > 0:
options.append(("grpc.keepalive_time_ms", config.keep_alive_time))
Workaround
Set keep_alive_time explicitly when creating the provider:
provider = FlagdProvider(
host="flagd",
port=8015,
resolver_type=ResolverType.IN_PROCESS,
keep_alive_time=600000, # 10 minutes
)
Or via environment variable:
FLAGD_KEEP_ALIVE_TIME_MS=600000
Environment
openfeature-provider-flagdversion: 0.2.7- flagd version: v0.13.2
- Python: 3.11 (aarch64-linux-gnu)
- grpcio: compiled with C-core (not pure-Python)
- Platform: Raspberry Pi 5 (ARM64)
- Ngôn ngữ chính
- Python
- Star
- 27
- Fork
- 33
- Merge trung bình
- 1 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 20
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của open-feature/python-sdk-contrib
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
open-feature/python-sdk-contrib#439 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
UnleashProvider.track has the wrong signature: client.track raises TypeError instead of no-opCó thể đã có người làm @aepfli đã nhận 30 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
open-feature/python-sdk-contrib#433 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Restore the .gitmodules branch pins so Renovate tracks flagd submodule versions againCó thể đã có người làm @aepfli đã nhận 34 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
open-feature/python-sdk-contrib#421 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
open-feature/python-sdk-contrib#417 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 28/100
open-feature/python-sdk-contrib#460 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của open-feature/python-sdk-contrib
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
SwiftKickMobile/skai#84 ·
-
Lychee link check failedĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
jxxghp/MoviePilot#7070 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
flop-labs/technocore-chat#997 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
doronz88/pymobiledevice3#2051 ·
Maintainer thường phản hồi trong vòng 1 ngày