Standardize how scenarios report setup/execution failures
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
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- typescript
- Lĩnh vực
- testing
Hướng nghiên cứu
Bắt đầu bằng cách đọc các phần triển khai scenario và tiện ích client-helper.ts được đề xuất, sau đó so sánh cách các lỗi thiết lập và thực thi hiện được báo cáo. Quyết định quy ước về lỗi thiết lập được mô tả trong issue và xác minh rằng các scenario báo cáo lỗi một cách nhất quán, đồng thời giữ nguyên hành vi của --suite, --scenario và expected-failures.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
A scenario that can't execute (connect failure, fixture missing, capability not advertised) should count as a FAILURE. The escape hatches are scenario filtering (--suite/--scenario) and the expected-failures baseline (#99) — not in-scenario skipping or silent passes.
Today every scenario hand-rolls this: most wrap the body in one big try/catch and emit their primary check ID as FAILURE on any error. That's fine for single-check scenarios but gets awkward with multiple checks at different severities (#200 discussion) — which check ID gets the connect failure is arbitrary, and the error message ends up under a label that has nothing to do with the actual problem.
Options:
- Emit all of the scenario's check IDs as FAILURE with the setup error message (consistent output shape)
- Emit a dedicated
<scenario-name>-setupcheck (semantically cleaner, but adds non-spec-mapped IDs) - A
client-helper.tsutility that scenarios call on setup failure, so the convention is enforced in one place
The helper is probably the best and then we can evolve the behavior from there. Having all the check-id's emitted requires a scenario knowing all its checks, which might be useful but is a larger change. The -setup check is probably reasonable as a first cut for this.
- Ngôn ngữ chính
- TypeScript
- Star
- 127
- Fork
- 101
- Merge trung bình
- 6 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 7
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 modelcontextprotocol/conformance
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
modelcontextprotocol/conformance#315 · 1 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
modelcontextprotocol/conformance#312 · 1 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 76/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 76/100
modelcontextprotocol/conformance#505 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Tất cả issue của modelcontextprotocol/conformance
Issue tương tự
-
comp/dashboard P3 type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
NousResearch/hermes-agent#117722 ·
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 76/100
-
code-quality refactoring
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
github/gh-aw-firewall#8816 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
langchain-ai/deepagents#6450 ·