Groq/Mistral specs are @stable but skip on every daily — components are not bundled in the image (and the recorded cause is wrong)

[rafaelgiln]

Summary

groq-provider.spec.ts and mistral-provider.spec.ts carry @stable, run in the daily shard, and skip on every run — they have skipped continuously since PR #917 landed the availability gate. The Groq and MistralAI components are not present in langflowai/langflow-nightly:latest, and per a product decision they will stay out of the image (still supported, but shipped as an installable bundle rather than bundled by default).

Four QA-CHECKLIST.md bullets count these two specs as validated [x], so the Coverage Summary and the generated Phase 0 — Validated block both credit coverage that never executes a single assertion.

Separately, the cause recorded in our code and issues is wrong for the current nightly — it is not a missing langchain-* package.

Measured on 1.12.0.dev8 (image built 2026-07-28T01:37, freshest digest)

1. Installed langchain-groq into the container and restarted → groq still absent from GET /api/v1/all. The langchain package is not the gate.
2. lfx/components/groq/__init__.py is now a deprecation shim:

   "Compatibility shim: lfx.components.groq moved to lfx-bundles. […] This module re-points to the installed bundle distribution. It contains no component implementations […] and is removed once the deprecation window closes (M4)."

3. The image installs ~20 per-vendor distributions — lfx_openai, lfx_anthropic, lfx_google, lfx_ollama, lfx_amazon, lfx_azure, lfx_cohere, lfx_ibm, lfx_datastax, lfx_vllm, lfx_openai_compatible, … There is no lfx_groq and no lfx_mistral.
4. lfx-groq / lfx-mistral do not exist in the package registry. lfx-bundles==1.1.5 does.
5. Installing lfx-bundles + restart restores them: catalog goes from 3,077,041 bytes / 37 categories to 4,313,696 bytes / 104 categories, with groq and mistral present. (Reverted afterwards — the container is back to the exact baseline byte size with both packages MISSING.)

Ollama is present on dev8 because lfx_ollama ships in the image, not because langchain-ollama returned.

Why not restore coverage with a bundle lane

uv pip install lfx-bundles + restart is cheap, but it cannot run in the default lane: it adds 67 component categories, changing the sidebar contents for every other spec, so the suite would stop validating the surface the shipped image actually delivers. It would need an isolated job with its own service container running only bundle-dependent specs — one extra daily job, an extra image matrix to maintain, for two provider specs.

Not worth it at this ratio. Demote instead, and keep the availability gate so the specs still work for anyone running against an image that has the bundles.

Scope

• Remove @stable from groq-provider.spec.ts and mistral-provider.spec.ts (a spec that always skips cannot carry the tag). Keep the isProviderComponentAvailable gate.
• Flip the four QA-CHECKLIST.md bullets from [x] to [~] — lines 421-422 and 1062-1063 — and state the reason in docs/core-functionality/model-provider/groq-provider.md and mistral-provider.md: not packaged in the tested image; requires lfx-bundles.
• Correct the attribution in tests/helpers/provider-setup/probe-component-available.ts (its header comment blames a missing langchain-* runtime package) and in both specs' skip messages, which cite langchain-mistralai missing (#907, LE-1987).
• Annotate REGRESSIONS.md row for LE-1987: the "missing langchain-* extras" mechanism described there was accurate for 1.12.0.dev3, but the current mechanism is the bundle split. Do not remove the row — the regression it records (silent hide with no message) was real and is fixed.
• Feed the correction into Harden collect-models: build-probe a provider's model class, not just the raw API key #900: its probe needs a declared per-provider expectation (expected in the image: yes/no) instead of a single boolean, and the inactive reason becomes "provider bundle not installed", not "model class cannot build". Without that split, Harden collect-models: build-probe a provider's model class, not just the raw API key #900's "fail loudly" requirement would make the daily permanently red for Groq/Mistral.

Non-goals

• Not reopening [Daily #906] Groq/Mistral provider config+run — waitForSelector 30s timeout (2 specs, recurrent) #907 / LE-1987. The absence is a product decision, not a regression.
• Not deleting the specs. Groq and Mistral remain supported providers; the specs are valid against an image with lfx-bundles.

Notes

The lfx-bundles migration itself has a much wider blast radius than these two specs — ~75 component families are now shims scheduled for removal at M4. Tracked separately.

[rafaelgiln]

Cross-links: the attribution correction feeds #900 (probe design — see that comment) and the wider migration is tracked in #1040.

[rafaelgiln]

Correction from validation: there are TWO gates, not one — and the langchain diagnosis still holds

Validating this issue's change turned up evidence that contradicts part of the original body. Correcting it here rather than silently shipping the wrong explanation.

The issue said component presence is a packaging decision and that "installing langchain-groq does not bring the component back, installing lfx-bundles does." The first half is right; the second is incomplete. Both gates are real and they compose:

State	groq registry	mistral registry	Groq run
default image (no lfx-bundles, no extras)	absent	absent	n/a — spec skips
+ lfx-bundles only	ext:groq:GroqModel@official present	category present but EMPTY	fails
+ lfx-bundles + langchain-groq + langchain-mistralai	present	ext:mistral:MistralAIModelComponent@official present	passes

Two things fall out of that middle row:

1. Mistral is dependency-gated, exactly as [Daily #906] Groq/Mistral provider config+run — waitForSelector 30s timeout (2 specs, recurrent) #907 / LE-1987 described. lfx-bundles ships lfx_bundles/mistral/mistral.py, but without langchain-mistralai the component never reaches the registry. That diagnosis was never superseded — it is one of the two gates.
2. A registry hit does not prove the component can build. With lfx-bundles installed and langchain-groq missing, Groq is placeable on the canvas and the Playground run dies with:

ComponentBuildError: Error building Component Groq:
langchain-groq is not installed. Please install it with `pip install langchain-groq`.

The spec failed on the empty-chat-message assert (getByTestId('div-chat-message') never appears, 60s) — a symptom several layers away from the cause.

Consequence for #900

This matters more there than here. A catalog-only probe would have marked Groq available in that middle state and let the spec run into a 60s timeout. The cheap /api/v1/all check answers "is it placeable", not "will it run" — so the build-probe I argued was probably unnecessary is back on the table for the exposed-but-unbuildable case. Posted separately on #900.

Validation performed

With lfx-bundles + both langchain extras installed on 1.12.0.dev8:

✓ groq-provider.spec.ts    (18.3s)  sentinel echoed: input reached the Groq model
✓ mistral-provider.spec.ts (10.5s)  sentinel echoed: input reached the Mistral model
2 passed (31.0s)

Force-fail (reply assert inverted to toBeLessThan(0), marked // FF-MUTATION) — both red, then reverted:

✘ groq-provider.spec.ts:93     expect(received).toBeLessThan(expected)   line 214
✘ mistral-provider.spec.ts:93  expect(received).toBeLessThan(expected)   line 209
2 failed

So the two specs are demonstrably correct and still catch a real break. What they cannot do is run on the image this suite validates — which is the whole point of dropping @stable.

Container restored to the pristine nightly afterwards: catalog back to 3,077,041 bytes / 37 categories, all three packages MISSING, and the specs skip again. No flows leaked by the passing runs.