Vladimir Blagojevic

> I have the impression that we should clarify the goal of this task. > > In general, I would like to avoid errors in snippets, but also readability for...

> > @anakin87 the goal is to make sure that pydocs are not just some hand-waving examples that actually don't work. As in usage of tiny whisper model that doesn't...

@dfokina I'll let you decide here for these changes. I'm ok with whatever you think is the best direction for audio and builders and in the meantime I'll remove the...

Hey @datbth what are you trying to achieve (i.e. what is your higher level scope/objective)? IMHO it's a bit odd to trace this hierarchy via tool call ids - it...

@sjrl if we don't hear from @datbth please consider closing this issue

Here is the current tracing output structure with this field added: ``` { "haystack.component.name": "chat_generator", "haystack.component.type": "OpenAIChatGenerator", "haystack.component.type_fqn": "haystack.components.generators.chat.openai.OpenAIChatGenerator", "haystack.component.input_types": { "messages": "list", "tools": "list" }, "haystack.component.input_spec": { "messages": {...

It is hard to properly fix https://github.com/deepset-ai/haystack-core-integrations/issues/2050 without resolving this issue. And we might likely need this fix anyway. It's a straightforward improvement/fix without any risk, only benefits.

> Alternatively [@vblagoje](https://github.com/vblagoje) to be more consistent with how we normally provide fully qualified types in our other type fields we could change the `"haystack.component.type"` to have the fully qualified...

@silvanocerza can you take over this one please?