Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

WARNING severity is inconsistent between client and server runners (client warnings can block Tier 1, server warnings cannot)

Aperta
  • Qualcosa non va?
#430 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 7 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
testing-qa

Direzione di ricerca

Leggi src/runner/client.ts, src/runner/server.ts, src/expected-failures.ts e src/tier-check/tier-logic.ts per confrontare in che modo WARNING influisce sulle esecuzioni, sulle baseline e sui tassi dei tier. Esegui i test pertinenti di conformance e tier-check, quindi conferma quale semantica di WARNING viene scelta e verifica che tutti e tre i percorsi la applichino in modo coerente senza modificare i risultati correnti di Tier 1.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

The two runners treat WARNING checks differently:

  • Client runner (src/runner/client.ts): overallFailure = failed > 0 || warnings > 0 || ... — any WARNING fails the scenario run.
  • Server runner (src/runner/server.ts): the pass/fail denominator counts only SUCCESS and FAILURE; warnings are reported but never affect the result.

Since tier-check requires pass_rate = 1.0 for Tier 1 on both conformance and client_conformance (src/tier-check/tier-logic.ts), the same severity mapping (SHOULD → WARNING) is a Tier 1 blocker on the client side but cosmetic on the server side. Whether an SDK's tier is affected by a SHOULD-violation currently depends on which side of the wire the scenario tests, which is hard to defend in a tiering dispute.

Related: src/expected-failures.ts counts WARNING as failure in baseline mode, which is a third distinct behavior.

Ask

Pick one semantic and apply it in both runners (and baseline mode). Options:

  1. Warnings never fail runs or tiers anywhere (server behavior today); SHOULD compliance becomes report-only.
  2. Warnings fail everywhere (client behavior today); Tier 1 then requires SHOULD compliance on both sides.
  3. Keep warnings non-failing for the run but surface a separate SHOULD-compliance rate in tier-check so tiering can reference it explicitly.

Context: noticed while landing #322, whose DELETE-status check is a WARNING because the spec pins no success status (#429). No current Tier 1 SDK emits warnings on either side, so any of the above can land without demoting anyone today.

Lingua principale
TypeScript
Stelle
130
Fork
107
Merge medio
8g 19h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/conformance

Tutte le issue di modelcontextprotocol/conformance

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.