feat(conversation): add iFlytek Spark conversation component

[FenjuFu]

Description

Adds an iFlytek Spark conversation component.

iFlytek Spark exposes an OpenAI-compatible chat-completions endpoint
(https://spark-api-open.xf-yun.com/v1), so this component is a thin
declarative provider built on the shared langchaingokit LLM and
BuildOpenAIClientOptions, mirroring the existing deepseek provider.

Metadata:

• key (required, secret) – the iFlytek Spark HTTP API password from the open-platform console
• model (optional) – defaults to generalv3.5
• endpoint (optional) – defaults to https://spark-api-open.xf-yun.com/v1
• maxTokens (optional)

Issue reference

N/A – new optional component, no behavior change to existing providers.

Checklist

• Code compiles correctly (mirrors conversation/deepseek)
• Created/updated component metadata (metadata.yaml)
• Runtime registration in dapr/dapr (follow-up PR after this merges and go.mod is bumped)
• Reference docs in dapr/docs (setup-spark.md, follow-up)

Follow-ups

1. Register the component in dapr/dapr (cmd/daprd/components/conversation_spark.go) once this is merged and the components-contrib dependency is updated.
2. Add the setup-spark.md reference doc under dapr/docs.

[FenjuFu]

Gentle ping @dapr/maintainers-components-contrib — this has been open for about three weeks. The component mirrors conversation/deepseek (OpenAI-compatible thin wrapper) and is ready for review; the workflows still need first-time-contributor approval to run. Happy to address any feedback or rebase if needed.

[mikeee]

Could you please elaborate on what this would add if it's using an openai compatible api would using that component not already accommodate?

Without extensive tests this would add a lot of maintenance burden on upgrades/updates.

Keen to hear your thoughts on this.

https://docs.dapr.io/reference/components-reference/supported-conversation/openai/

[FenjuFu]

Thanks @mikeee, that's a fair question — let me be upfront about what this does and doesn't add.

You're right that technically the openai component already accommodates Spark: its endpoint is OpenAI-compatible, so pointing the existing openai component at https://spark-api-open.xf-yun.com/v1 with an arbitrary model works. This component doesn't add any protocol handling on top of that — it's the same thin langchaingokit wrapper as deepseek, differing only in the two default constants (generalv3.5 / the Spark base URL).

So the case for it is exactly the case for the existing per-vendor conversation components (deepseek, mistral, googleai, huggingface, ollama), which are all the same shape:

• Discoverability — Spark shows up in the supported-conversation list and docs, rather than users having to know it's "openai with this specific endpoint + model."
• Sensible defaults — the endpoint and a working default model are baked in.

I don't want to overstate it though: it's convenience + consistency, not new capability. So I'll defer to your read on the tradeoff:

1. If you'd like to keep it in line with the existing vendor components, I'm happy to add unit tests (metadata + init) — I can mirror what openai/anthropic have. Worth noting deepseek/mistral/googleai/ollama currently ship without tests, so this would actually raise the bar rather than match the (untested) precedent.
2. If the direction is instead to steer people toward the generic openai component + custom endpoint and not grow more thin per-vendor wrappers, that's completely reasonable — I'm fine closing this, and I'd be glad to instead send a small docs PR to the openai conversation reference noting that OpenAI-compatible Chinese endpoints (Spark, etc.) work via the endpoint field, so the discoverability gap is still addressed.

Let me know which you'd prefer and I'll follow up accordingly.