Files
OmniRoute/tests/integration
anhtahaylove 1603c86e06 test: realign two stale assertions with product behavior (#13313) (#13315)
* test: expect the jina alias prefix in the custom-model catalog case

The custom-model assertions expected ids prefixed `jina-ai/`, but the catalog
prefixes model ids with the provider alias, which is `jina`. The synced-model
test directly above asserts `jina/` and passes, so the two cases contradicted
each other within the same file.

The expectation predates the alias: the test was written in v3.7.9 (2026-05-04)
and `alias: "jina"` was added in v3.8.36 (2026-06-25).

Aligns the two assertions with the sibling test and with the product. The file
now passes 44/44 (was 43 with 1 failure).

Confirmed the assertions still bite: renaming the alias to `jina-XX` fails
exactly these two cases.

* test: pin the pt-BR pack in the two language-pack fixtures

Both tests assert the Portuguese output-style string but configured
languageConfig with enabled:false and defaultLanguage:"en".
resolveOutputStyleLanguage returns "en" on its first line when enabled is not
true, so the English pack was injected and the assertion could never hold.

autoDetect:true would not have helped either: the user turns in these fixtures
are English, so the detector resolves back to "en". The pack under test has to
be pinned, hence autoDetect:false with an explicit defaultLanguage.

This restores coverage rather than just turning the suite green. Mutating the
pt-BR pack string in outputMode.ts now fails exactly these two tests; with the
old fixture the file reported 9 pass / 2 fail whether the pack was intact or
mutated, so it detected nothing. File is 11/11 (was 9 + 2 failures).

The third languageConfig fixture in this file belongs to an rtk test that makes
no language assertion and is left untouched.

* test: keep the canonical jina-ai prefix in the catalog case

Reverts 8d371d4. The catalog file holds two Jina cases that are not the
same scenario: the custom-model/alias case legitimately expects the
`jina/` alias prefix, while the specialty-model case expects the
canonical provider id `jina-ai/`. Aligning the second to the first reads
like a fix but changes a passing assertion into a failing one.

Verified against the current release tip by mutation, both directions:
the specialty case passes as `jina-ai/...` and fails as `jina/...`, with
the runner reporting `actual: 'jina-ai/jina-embeddings-v5-text-small'`.
The canonical ids are what the source declares — `embeddingRegistry.ts`
and `rerankRegistry.ts` both key the provider as `jina-ai`, as does
EMBEDDING_RERANK_PROVIDER_IDS in src/shared/constants/providers.ts.

The pt-BR language-pack commit on this branch is untouched: that one is a
real fix and repairs two genuinely failing assertions.

---------

Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
2026-09-17 22:13:39 -03:00
..
2026-07-04 13:00:30 -03:00
2026-07-02 10:47:13 -03:00
2026-07-29 15:18:55 -03:00
2026-05-23 01:46:59 -03:00