test(httpclient): pin that the shared httpcalls client keeps no cookie jar

[ginccc]

The problem

The Vert.x client behind every agent's httpcalls was once wrapped in an application-scoped WebClientSession, which keeps a cookie store. A Set-Cookie from one call would then be replayed on later calls to the same host from any agent, conversation, user or tenant.

#862 already replaced it with a plain WebClient, so main is not vulnerable. But nothing pinned that behaviour: reintroducing a session (an easy "improvement") would pass every existing test.

What this PR does

No production code changes.

• HttpClientModuleCookieTest runs the real provideHttpClient producer against a loopback com.sun.net.httpserver server that answers every request with Set-Cookie, and asserts the second request carries no Cookie header.
• docs/httpcalls.md: new "Cookies are not kept between calls" section, since an API that relied on a session cookie now needs an explicit header.
• Corrects a stale comment in ApiCallExecutorBranchCoverageTest that still described a cookie-aware session.
• Changelog fragment.

What this breaks

Nothing new. Stored configs, REST paths, MCP tools and property names are untouched. Behaviour is as already shipped by #862: no cookie persistence between httpcalls.

What a reviewer should look at hardest

The test reaches module.vertx (package-private) and calls the producer directly instead of booting Quarkus; confirm that is an acceptable seam.

Verification

• HttpClientModuleCookieTest, HttpClientModuleTest, ApiCallExecutorBranchCoverageTest plus the repo-wide guards (ImportStyleTest, BuildQualityGatesTest, ChangelogRotationTest, ChangelogFragmentTest, DocumentationLinksTest, DocumentationAccuracyTest, DocumentedRestPathsTest): 122 tests, 0 failures, every class confirmed to have a report.
• Mutation check: swapping WebClientSession.create(webClient) back into the producer makes the new test fail with Set-Cookie from the first call was replayed on the second: JSESSIONID=TENANT-A-SECRET; restored afterwards.
• Not run locally: the full ./mvnw test suite and integration tests (CI). Locally the test needs a short TEMP path on Windows.

Summary by CodeRabbit

• Documentation
  • Clarified that HTTP calls do not retain cookies: cookies received in a response are not sent with later calls or saved in conversation memory. Include any credentials needed for follow-up calls explicitly, such as in a request header or property.
• Tests
  • Added coverage verifying that cookies are not reused between calls and that requests continue to receive successful responses.

[github-actions]

⚠️ Deprecation Warning: The deny-licenses option is deprecated for possible removal in the next major release. For more information, see issue 997.

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

🧰 Additional context used

📚 Code guidelines (4)

docs/changelog.d/README.md — auto-discovered
AGENTS.md — auto-discovered
.claude/skills/ship-pr/SKILL.md — Agent Skill
.cursor/rules/project-context.mdc — auto-discovered

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1fdc9668-2070-4ed5-8428-0661c48de9d5

📥 Commits

Reviewing files that changed from the base of the PR and between 0436680 and 783b932.

📒 Files selected for processing (4)

• docs/changelog.d/2026-10-05-fix-httpclient-no-cookie-jar-test.md
• docs/httpcalls.md
• src/test/java/ai/labs/eddi/engine/httpclient/bootstrap/HttpClientModuleCookieTest.java
• src/test/java/ai/labs/eddi/modules/apicalls/impl/ApiCallExecutorBranchCoverageTest.java

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The PR adds a loopback regression test for cookie handling by the shared HTTP client. It also documents that cookies are not retained between calls and updates a test comment and changelog entry.

Changes

HTTP client cookie behavior

Layer / File(s)	Summary
Test and document cookie handling src/test/java/ai/labs/eddi/engine/httpclient/bootstrap/HttpClientModuleCookieTest.java, docs/httpcalls.md, src/test/java/ai/labs/eddi/modules/apicalls/impl/ApiCallExecutorBranchCoverageTest.java, docs/changelog.d/2026-10-05-fix-httpclient-no-cookie-jar-test.md	The loopback test checks that two requests return status 200 and neither sends a Cookie header after Set-Cookie responses. The documentation and test comment describe the client’s cookie behavior and the need to pass follow-up credentials explicitly. The changelog records these changes.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Suggested reviewers: rolandpickl

Merge Risk: ⚪ Minimal · up to 783b9

The new test and documentation clarify the existing cookie behavior. No actionable merge risk remains after normal checks.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to 783b9

The change protects an existing security boundary through documentation and regression coverage. It does not introduce cookie persistence, new production entrypoints, or additional credential sharing.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — Cookie-state isolation is important because the producer is application-scoped and documented as serving all agents and users. Introducing an application-wide cookie store would therefore create a cross-principal sharing surface, but this PR does not introduce such a store or broaden its exposure.

Trust Boundaries and Controls

• observed — The relevant boundary separates remote response credentials from later callers and persisted conversation context. The unchanged producer uses a plain WebClient rather than WebClientSession, while the unchanged executor drops Set-Cookie from captured response headers before persistence.

Resilience and Maintainability Implications

• inferred — The new test supplies a regression guard against accidental reintroduction of shared cookie persistence. Its state is test-owned: requests are sequential, observations use a thread-safe list, waits are bounded, and teardown stops the listener and closes Vert.x. This is not evidence of production cancellation, concurrency, or recovery guarantees.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (2 skipped: 2…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: adding a regression test that confirms the shared httpcalls client does not keep a cookie jar.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. (2 skipped: 2 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[ginccc]

Disposition of the un-threaded feedback on this PR (there are no review threads and no reviews yet):

• Dependency Review — clean result; the deprecation notice concerns the deny-licenses option in the workflow itself, not this change. No action.
• CodeRabbit — "no actionable comments" — the review completed (check description: "Review completed"), but it ran under the chill profile, which deliberately does not raise style-level nitpicks, so this is not a sweep for them.
• CodeRabbit — Docstring Coverage 25% (threshold 80%) — not acting on it. The count is over 4 functions in 2 files and is dominated by test lifecycle and test methods, which carry @DisplayName instead of Javadoc in this codebase. It is an advisory pre-merge check and does not gate the merge.

CI: every check is green except Integration Tests, still running; the skipped jobs are explained by Detect Changes (no UI or shell changes).