Test coverage for signed-in flows: fakes in CI, production canary, release checklist
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ó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start with the listed agent client directories and the existing callable routing split, then review sub-issues #1615–#1619 to find the scoped implementation work. This issue defines a multi-part testing strategy across fakes in CI, a production canary, and a release checklist; done means those parts are implemented as their sub-issues specify.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Goal
Cover signed-in flows (sign-in, send, receive, moderate, signed-in settings). Today nothing covers them: the integration suite signs in anonymously against the Auth emulator with a seeded profile and never calls a callable.
Approach
Real-account tests in CI would need a token vault with rotation (Kick refresh tokens change on every refresh), a public webhook tunnel, serialized runs, and constant upkeep. Instead, split the problem into three parts, as most apps that integrate with streaming platforms do:
| Catches | Where | Sub-issue | |
|---|---|---|---|
| Fakes in CI | Our bugs in signed-in flows | Every PR, required check | #1615, #1616, #1617 |
| Production canary | Twitch or Kick changing their API, scopes or webhook delivery | Production agent, every few minutes | #1618 |
| Release checklist | Breakage on the third-party sign-in pages | Manual, before each release | #1619 |
1. Fakes in CI
- Twitch: use the official Twitch CLI.
twitch mock-apiserves Helix with fake users and tokens;twitch event trigger/twitch event websocketsend fake EventSub events. - Kick: no official mock exists, so write a small fake server covering only the endpoints we call: users, channels, chat, moderation, events/subscriptions. It also posts signed webhook deliveries using a test key pair.
- Backend: point the backend's platform clients at the fakes through config. Most agent clients already take a
BaseURL(agent/internal/clients/{twitch,kick},jobs.TwitchURL/KickURL); a few hostnames are still hardcoded. - Signing in: mint a custom token from the Auth emulator for a seeded user and deliver
com.rtirl.chat://success?token=…to the app. This runs the real app path except the third-party sign-in page. - Optional: record real API responses once, by hand, and replay them in the fakes so they don't drift from production.
Cloud Functions migration (#1551): callables are split between the Go agent and Cloud Functions behind rtchat-api.rtirl.com. The harness runs the agent for callables it already serves, and the Functions emulator only for the ones not yet migrated. One routing table holds that split, so each migration step only edits the table. Put fake-server config in the agent first. Only add it to Functions for callables that haven't moved yet; don't invest further in Functions code that's being retired.
2. Production canary
A dedicated canary bot account on each platform signs in once through the real app. From then on, production already stores and refreshes its token, so there's no vault and no tunnel. A scheduled agent job:
- sends a message with a unique ID to the canary's own channel through the normal send path
- checks that the message comes back through the webhook or EventSub into Firestore
- cleans up after itself
Failures are logged in a structured form, and a Cloud Monitoring alert on those logs notifies the team.
3. Release checklist
Before each release, sign in with each platform on a real device. It takes a couple of minutes, and every app keeps this step manual because the sign-in pages resist automation.
Sequencing
- #1615 (fakes) → #1616 (CI harness) → #1617 (test cases)
- #1618 (canary) runs independently
- #1619 (checklist) can be done anytime
- The multi-session E2E (#1611) builds on #1616's harness once both have landed.
Out of scope
Real platform accounts in CI. Automating third-party sign-in pages.
- Ngôn ngữ chính
- Dart
- Star
- 49
- Fork
- 25
- Merge trung bình
- 10 giờ 43 phút
- Pull request đã merge (30 ngày)
- 217
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
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 muxable/rtchat
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 57/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của muxable/rtchat
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] 附近设备权限未申请Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
bggRGjQaUbCoE/PiliPlus#3369 ·
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 65/100
-
[lsp] Remove DartAnalysisServerService.serverReadyForRequest() from EnableDartSupportForModuleĐang mởP1
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
flutter/flutter-intellij#9177 ·
Maintainer thường phản hồi trong vòng 1 ngày