Concurrent requests overwrite each other's instrumentation data

Aperta
  • Qualcosa non va?
#657 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@atesgoral ci sta già lavorando.

Dal 6/11/2026.

  • #668 di @atesgoral — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
ruby
Ambito
backend, observability

Direzione di ricerca

Start with lib/mcp/instrumentation.rb, especially instrument_call and add_instrumentation_data, then read the concurrent shared server test in test/mcp/server_test.rb and the tool call instrumentation in lib/mcp/server.rb. Reproduce the interleaving described in the issue and check how request data reaches the callback; done when concurrent requests produce separate records with the correct tool names. An open pull request (#668) is already addressing this issue.

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

Descrizione

bug

Instrumentation#instrument_call keeps the per-request record in @instrumentation_data, an instance variable on the shared Server (instrumentation.rb:8). When two requests run at the same time on one server, for example Streamable HTTP on a threaded Rack server, the second request replaces the hash.

The first request then writes its later fields (client, error, duration) into the second request's hash and passes that hash to instrumentation_callback (instrumentation.rb:43, :48). The first request's own record, with its tool_name and tool_arguments (server.rb:1408), is never sent to the callback. around_request gets the original hash (instrumentation.rb:17) but misses the fields written after the swap.

Concurrent use of one server is supported (see test "#handle concurrent requests on a shared server report exceptions independently" in test/mcp/server_test.rb).

Repro

Run from the repository root with bundle exec ruby -I lib repro.rb:

require "mcp"

entered = Queue.new
release = Queue.new
slow_tool = MCP::Tool.define(name: "slow_tool") do
  entered << true
  release.pop
  MCP::Tool::Response.new([{ type: "text", text: "slow" }])
end
fast_tool = MCP::Tool.define(name: "fast_tool") do
  MCP::Tool::Response.new([{ type: "text", text: "fast" }])
end

records = Queue.new
configuration = MCP::Configuration.new
configuration.instrumentation_callback = ->(data) { records << data.dup }
server = MCP::Server.new(name: "example", tools: [slow_tool, fast_tool], configuration: configuration)

call = ->(id, name) { server.handle({ jsonrpc: "2.0", id: id, method: "tools/call", params: { name: name, arguments: {} } }) }
thread = Thread.new { call.call(1, "slow_tool") }
entered.pop
call.call(2, "fast_tool")
release << true
thread.join

p(2.times.map { records.pop[:tool_name] })

Expected: ["fast_tool", "slow_tool"]

Actual: ["fast_tool", "fast_tool"]

Suggested fix

Keep the record local to the request instead of on the shared server. For example, create the hash in instrument_call and pass it to add_instrumentation_data, or keep it in a fiber-local value that instrument_call sets and restores.

Lingua principale
Ruby
Stelle
940
Fork
143
Merge medio
1g 5h
PR unite (30g)
48

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/ruby-sdk

Tutte le issue di modelcontextprotocol/ruby-sdk

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.