[flagd] Should shutdown stop the connectivity watcher? In-process leaves "Cannot invoke RPC: Channel closed!"
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Bắt đầu từ provider.shutdown() của Python in-process resolver và gRPC connectivity watcher được mô tả trong issue. Tái hiện kịch bản vòng đời từ cross-language provider conformance suite và kiểm tra thứ tự shutdown. Được xem là hoàn tất khi shutdown vẫn hoàn thành trong giới hạn của nó mà không để lại traceback hoặc log cấp ERROR từ watcher.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Asking rather than reporting, because nothing required is unmet here — the shutdown completes, and well within the bound. What it leaves behind is a traceback in the host application's log, and I would like to know whether that is known and intended.
What I see
In-process resolver. After provider.shutdown():
ValueError: Cannot invoke RPC: Channel closed!
raised from gRPC's connectivity poller, after the shutdown call has already returned successfully.
The reading that fits: shutdown() closes the gRPC channel, but the watcher task observing channel connectivity is still running and calls into the closed channel on its next poll. Nothing retries and nothing fails — the provider is down by then and the application is not asking it for anything — so the only symptom is the traceback.
Why it may be worth fixing anyway
An application that shuts down cleanly still gets a stack trace on the way out. That is noise at the exact moment operators are reading logs to find out whether shutdown was clean, and it trains them to ignore tracebacks from this path — which is where a real error would also appear.
It is also the kind of thing that becomes a test failure elsewhere: a suite configured with -W error, or one asserting nothing is logged at ERROR, would fail on a provider that is behaving correctly.
Questions
- Is the watcher meant to be stopped before the channel closes, or is the traceback known and considered harmless?
- If it should be stopped — is that
shutdown()'s job, or should the watcher tolerate a closed channel and exit quietly? - Is there a reason the ordering is hard here that I am not seeing? I have not attempted a fix, because the answer to (2) decides what a fix would look like.
How I found it
Building the cross-language provider conformance suite proposed in
open-feature/spec#417. The relevant detail is that
the scenario passes — it asserts that shutdown completes within a bound, and it does. The
traceback is beside the assertion, not in it.
That is also why it went unnoticed for some time: the Python adoption had not declared the
@lifecycle capability, so the six lifecycle scenarios had never run against flagd at all. Declaring
it was a one-line change and this surfaced on the first run. The other three languages' adoptions
have been running those scenarios throughout and do not show anything equivalent, so this looks
specific to the Python in-process resolver rather than to the shape of the test.
- 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
-
flagd: remove deprecated sync.GetMetadata RPC call (use sync_context)Có thể đã có người làm @buildingisfun23 đã nhận 1 ngày trước. Đang mở
Độ 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 32 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 36 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ự
-
Use mhctools predictor_required=False for saved-result rescoringCó thể đã có người làm @iskandr đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
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 79/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
521xueweihan/HelloGitHub#4051 · 1 bình luận ·
-
bug documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
awslabs/visual-asset-management-system#514 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend bug spec:REQ-053
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
nolte/kamerplanter#2547 ·
Maintainer thường phản hồi trong vòng 1 ngày