Two SEPs on main describe incompatible surfaces for the same mechanism, and the stale one reads as current.
The contradiction
docs/seps/2322-MRTR.mdx describes the persistent (stateful) multi-round flow using tasks/result and tasks/input_response — around lines 884, 886, 901, 907 and 920. It states "We propose tasks/input_response", in present-tense proposal language.
docs/seps/2663-tasks-extension.mdx — badged Final, Extensions Track — removed both:
:31 gives the surface as "three methods: tasks/get, tasks/update, and tasks/cancel".:56 says it "consolidates the polling lifecycle into tasks/get and a new tasks/update to remove the blocking tasks/result method.":49 heads the problem statement: "tasks/result is a blocking trap … forces long-lived persistent connections … conflicts with SEP-2260.":202, :364-366 and :386 show input answered via the inputResponses field on a tasks/update request, not a dedicated method.:53 describes departing from SEP-1686, the predecessor.
So tasks/result was removed, and tasks/input_response never existed in the Final surface.
Why this is worth fixing rather than leaving to readers
Someone reading SEP-2322 to implement MRTR — the natural entry point, since it is the document that defines multi-round retrieval — comes away with two method names a conformant server must not implement and a client will never call. Nothing in SEP-2322 signals that its persistent-flow section was superseded.
We hit exactly this. An implementation reached for tasks/result and tasks/input_response on SEP-2322's authority and wrote them into architecture documentation as the sanctioned path for stateful input_required work. It was caught only when a reviewer cross-checked SEP-2663 directly. The failure mode is quiet, because the wrong surface is internally coherent and cites a real, current SEP.
The incorrect names will also keep propagating: SEP-2322 is what search and documentation tooling surfaces for MRTR questions, being the document whose subject matter is multi-round retrieval.
Suggested fix
Either update SEP-2322's persistent-flow section to SEP-2663's actual surface (tools/call returns resultType: "task" with a taskId; the client polls tasks/get and answers outstanding inputRequests via inputResponses on tasks/update), or add a superseding note at the head of that section pointing at SEP-2663 and marking the described methods as removed. The second is cheaper and would have been enough to prevent our error.
Happy to open a PR for either shape.
Verification
Both files were read from main at filing time rather than from an indexed copy — line numbers are from the .mdx files as fetched. Worth mentioning because a documentation index served a stale snapshot of a different SEP during the same investigation, producing a phantom error-code discrepancy that evaporated against the raw file; the raw files were used deliberately here to avoid repeating that.
Two SEPs on
maindescribe incompatible surfaces for the same mechanism, and the stale one reads as current.The contradiction
docs/seps/2322-MRTR.mdxdescribes the persistent (stateful) multi-round flow usingtasks/resultandtasks/input_response— around lines 884, 886, 901, 907 and 920. It states "We proposetasks/input_response", in present-tense proposal language.docs/seps/2663-tasks-extension.mdx— badged Final, Extensions Track — removed both::31gives the surface as "three methods:tasks/get,tasks/update, andtasks/cancel".:56says it "consolidates the polling lifecycle intotasks/getand a newtasks/updateto remove the blockingtasks/resultmethod.":49heads the problem statement: "tasks/resultis a blocking trap … forces long-lived persistent connections … conflicts with SEP-2260.":202,:364-366and:386show input answered via theinputResponsesfield on atasks/updaterequest, not a dedicated method.:53describes departing from SEP-1686, the predecessor.So
tasks/resultwas removed, andtasks/input_responsenever existed in the Final surface.Why this is worth fixing rather than leaving to readers
Someone reading SEP-2322 to implement MRTR — the natural entry point, since it is the document that defines multi-round retrieval — comes away with two method names a conformant server must not implement and a client will never call. Nothing in SEP-2322 signals that its persistent-flow section was superseded.
We hit exactly this. An implementation reached for
tasks/resultandtasks/input_responseon SEP-2322's authority and wrote them into architecture documentation as the sanctioned path for statefulinput_requiredwork. It was caught only when a reviewer cross-checked SEP-2663 directly. The failure mode is quiet, because the wrong surface is internally coherent and cites a real, current SEP.The incorrect names will also keep propagating: SEP-2322 is what search and documentation tooling surfaces for MRTR questions, being the document whose subject matter is multi-round retrieval.
Suggested fix
Either update SEP-2322's persistent-flow section to SEP-2663's actual surface (
tools/callreturnsresultType: "task"with ataskId; the client pollstasks/getand answers outstandinginputRequestsviainputResponsesontasks/update), or add a superseding note at the head of that section pointing at SEP-2663 and marking the described methods as removed. The second is cheaper and would have been enough to prevent our error.Happy to open a PR for either shape.
Verification
Both files were read from
mainat filing time rather than from an indexed copy — line numbers are from the.mdxfiles as fetched. Worth mentioning because a documentation index served a stale snapshot of a different SEP during the same investigation, producing a phantom error-code discrepancy that evaporated against the raw file; the raw files were used deliberately here to avoid repeating that.