Adrian Cole

ok fair enough, just the type `SynchronousMultiTracingProcessor` scared me about there being a non-synchronous future which would likely break things. My 2p is add tests to make sure you know...

`replace_processors=True`? I think whether we replace the tracer or not we are replacing the processors. If we say we are disabling other tracing, we should do that. As a benchmark...

gotcha, anyway `disable_other_tracing` gives us flexibility to straight-pipe to logfire should we decide to later

ps sorry I am slow on this. I have a conference this week which has unrelated work: allthingsopen.ai, so heads down on that. Someone can yank this if they like

sorry I've switched jobs and this particular piece isn't in my foreground at the moment. Please no-one block on me

ps here's the langchain workaround until this is in. While not perfect, certainly proceeds! ```python # Until https://github.com/ollama/ollama/issues/5907, we cannot use OpenAIEmbeddings because it # produces embeddings requests with list...

not sure if this is helpful, but I see a PR for langchaingo's openai client https://github.com/tmc/langchaingo/pull/986

I would like this, even though it is an interesting challenge for trace propagation. Suggest we support stdio mode as well, even though that isn't typical for armeria. Rationale is...

sg. Also if you want a reference, this uses stdio in spring-ai. I think the integrations could be far cleaner in armeria https://github.com/elastic/observability-examples/pull/61

also here's a nice read of the latest non-stdio protocol "streamable" https://www.claudemcp.com/blog/mcp-streamable-http