fix(postman): pass explicit language in AI Search Related by identifier (#35780)

[dsolistorres]

Summary

Refs #35780. Follow-up to PR #35795 which fixed the same language=-1 class of failure in Workflow_Resource_Tests and GraphQLTests. AI was intentionally out of scope in that PR; this surfaces in the latest CI run as the only remaining Postman-side blocker.

What was diagnosed

CI run 26312707306 — PR Test / Postman Tests - AI failed on Search / Search Related by identifier:

expected response to have status code 200 but got 404

Server-side log during the failing request:

WARN  rest.SearchResource - unable to find matching contentlet for id:8d37011d-... inode: language:-1

Same language:-1 symptom as the rest of #35780. The test body is:

{"identifier": "{{identifier}}", "fieldVar": "seo"}

…with no language field. The endpoint at dotCMS/src/main/java/com/dotcms/ai/rest/SearchResource.java:

final long language = json.optLong(AiKeys.LANGUAGE,
        APILocator.getLanguageAPI().getDefaultLanguage().getId());

…falls back to getDefaultLanguage().getId() — which returns -1 (LANG__404 sentinel) in this test env. Then findContentletByIdentifier(id, -1) returns 404.

The CLI _makedefault fix in #35813 affects the CLI test dotCMS instance only — Postman jobs run their own separate Docker containers, so the test env state is unchanged here.

Changes

AI.postman_collection.json:

1. Top-level prerequest — adds the same GET /api/v2/languages/_getdefault resolver pattern shipped in fix(postman): pass explicit languageId in WorkflowResource + GraphQL tests (#35780) #35795 v2. Idempotent via pm.environment.get('defaultLanguageId') guard, throws on network error / non-200 / missing entity.id (no silent fallback to invalid JSON request bodies).

2. Failing test body — adds "language": {{defaultLanguageId}}. Note the key is "language" (per AiKeys.LANGUAGE), not "languageId".

Diff

+32 / −2 — surgical text patch that preserves the file's 2-space formatting (no full reserialize).

Test plan

• JSON validity verified.
• Pattern identical to fix(postman): pass explicit languageId in WorkflowResource + GraphQL tests (#35780) #35795 v2 (already approved in review).
• CI verifies — PR Test / Postman Tests - AI should pass on this branch.

🤖 Generated with Claude Code

[claude]

Claude finished @dsolistorres's task in 1m 50s —— View job

---

PR Review — #35816

• Read PR description and diff
• Compare against sibling pattern in Workflow_Resource_Tests.json (fix(postman): pass explicit languageId in WorkflowResource + GraphQL tests (#35780) #35795)
• Verify AiKeys.LANGUAGE = "language" matches the body key
• Verify server-side handling in SearchResource.java
• Post review

---

Clean. The two-commit patch matches the pattern shipped in #35795 v2, the body key ("language") matches AiKeys.LANGUAGE, and the prerequest is idempotent via the defaultLanguageId env guard. Worth flagging as second-look material, none blocking:

1. id=1 fallback is a hardcoded assumption (intentional, documented).
AI.postman_collection.json:3845 falls back to English when _getdefault returns ≤ 0. The inline comment says "English (id=1), which is always present in dotCMS starter data." That assumption holds for the default starter used in CI, but it would silently mis-target the wrong language if a future Postman job ever loaded a non-default starter. The throw-on-invalid behavior in the sibling collections (Workflow/GraphQL on main today) is louder and safer; the new "warn+fallback" version is friendlier but trades fail-fast for resilience. Worth keeping in mind if a non-standard starter is ever introduced.

2. Drift vs. sibling collections.
Workflow_Resource_Tests.json:19854-19856 and GraphQLTests.json currently throw on missing entity.id (no <= 0 check, no English fallback). The PR description says #35817 will sync those — until that lands, the three collections diverge. Worth confirming #35817 makes it in close to this one so they stay aligned. Not a blocker for this PR.

3. Nit: !id || id <= 0 (AI.postman_collection.json:3840).
!id already covers undefined, null, 0, NaN, "". The second clause exists only to catch negative ids (-1 sentinel). Functionally correct, just slightly redundant — id == null || id <= 0 reads more cleanly. Pure style, ignore.

4. Async semantics — verified, no issue.
pm.sendRequest is asynchronous within the script, but Postman's runtime awaits pending callbacks before firing the outgoing request, so {{defaultLanguageId}} is templated after the env var is set. Idempotent guard means subsequent requests are no-ops. Correct as written.

5. Server-side path — verified.
SearchResource.java:? reads json.optLong(AiKeys.LANGUAGE, …default…); with "language": 1 in the body, the default is bypassed entirely, so the getDefaultLanguage().getId() == -1 failure mode is sidestepped at the request layer. Surgical fix at the right boundary.

No correctness, security, or design concerns. Ship it once CI is green.
• Branch: issue-35780-ai-postman-language

[dsolistorres]

Pushed an additional commit that adds the same English-fallback handling shipping for Workflow + GraphQL in #35817. Without it, when _getdefault returns the LANG__404 sentinel (id=-1), our script blindly stored -1 as defaultLanguageId and the test body sent "language": -1 — same FK failure we have been fighting. Tightened the guard to id <= 0 and fall back to English (id=1).