Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

`_onprogress` raises a protocol error for a race servers cannot avoid (progress notification arriving with the response)

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#2,580 4 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@qiushui7 y travaille déjà.

Depuis le 30/7/2026.

  • #2967 par @feniix — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
typescript
Domaine
api

Piste de recherche

Commencez dans src/shared/protocol.ts en lisant _onresponse et _onprogress, puis reproduisez la race avec l’exemple callTool et les messages de progression et de réponse adjacents. C’est terminé lorsqu’une notification de progression tardive pour une requête terminée est ignorée sans déclencher _onerror, tandis que la transmission normale de la progression reste inchangée ; vérifiez s’il faut documenter le comportement de la notification terminale.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug P2 ready for work v1 v2
Summary

When a request completes, Protocol._onresponse deletes that request's progress handler. Any progress notification for the token that is processed afterwards falls into _onprogress, finds no handler, and is reported through _onerror:

Received a progress notification for an unknown token: {...}

Discarding the notification is reasonable — once the request is done, progress for it is moot. Raising a protocol error for it is not, because a server has no way to avoid producing that condition.

Why a server cannot avoid it

A server that reports progress for a batch operation naturally emits a terminal progress === total notification just before returning the result. Those two writes are adjacent by construction. Whether the client processes the notification before or after the response is a timing race the server does not control — and on a loaded machine it loses.

Concretely, in src/shared/protocol.ts:

// _onresponse
if (!isTaskResponse) {
  this._progressHandlers.delete(messageId);
}

// _onprogress
const handler = this._progressHandlers.get(messageId);
if (!handler) {
  this._onerror(new Error(`Received a progress notification for an unknown token: ...`));
  return;
}

So any server emitting a terminal progress notification will intermittently cause onerror to fire in every client. For hosts that log or surface protocol errors, a well-behaved server ends up manufacturing spurious error noise on a successful operation.

Attempting to fix it server-side does not work. Awaiting the notification sends before returning the result orders the writes correctly, but cannot prevent the client from tearing down its handler before it dispatches them.

Reproduction

Server emits N progress notifications then the result, with no artificial spacing between them. Client:

const progress: unknown[] = [];
const errors: string[] = [];
client.onerror = (e) => errors.push(e.message);

await client.callTool({ name: "export", arguments: { /* 3 items */ } },
  CallToolResultSchema, { onprogress: (p) => progress.push(p) });

Observed (server sent 4 notifications, all before the result):

received=1
errors=[
  'Received a progress notification for an unknown token: {"method":"notifications/progress","params":{"progress":1,"total":3,...,"progressToken":1}}',
  '...{"progress":2,...}',
  '...{"progress":3,...}'
]

One delivered, three discarded with an error each. With ~100ms spacing between notifications the same code delivers all four — i.e. it is purely a timing race, not a protocol violation by either side.

Observed with @modelcontextprotocol/sdk 1.29.0 over stdio.

Suggested change

Treat "progress notification for a request that has just completed" as an expected, benign race rather than an error:

  • don't route it to _onerror; ignore it silently, or log at debug level; or
  • keep a short grace period after response for recently-completed tokens and drop matching notifications quietly.

Either removes the false error without changing the (sensible) decision not to deliver late progress.

Secondary question

Is there any supported way for a server to deliver a terminal progress notification reliably? If not, that is worth stating in the spec/docs, so server authors know the final progress === total frame is inherently best-effort and clients know not to build completion UI on it. Right now it looks reliable, and fails only under load.

Langage dominant
TypeScript
Étoiles
13.7k
Forks
2.3k
Merge moyen
1 j 2 h
PR mergées (30 j)
60

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/typescript-sdk

Toutes les issues de modelcontextprotocol/typescript-sdk

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.