#5033 Fix scoped Sessions plugin not sending Set-Cookie without call.respond()

[fru1tworld]

Subsystem
Server, ktor-server-core (routing)

Motivation
Fixes #5033. Scoped Sessions plugin doesn't send Set-Cookie when handler sets status without call.respond().

Solution
Call respond() through RoutingPipelineCall when handler set status but didn't respond, so scoped sendPipeline interceptors fire.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e6c8065d-3b64-4c57-a240-6d551929b72a

📥 Commits

Reviewing files that changed from the base of the PR and between 049538f and 1b74906.

📒 Files selected for processing (2)

• ktor-server/ktor-server-core/common/src/io/ktor/server/routing/RoutingRoot.kt
• ktor-server/ktor-server-tests/common/test/io/ktor/tests/server/sessions/SessionTest.kt

🚧 Files skipped from review as they are similar to previous changes (2)

• ktor-server/ktor-server-core/common/src/io/ktor/server/routing/RoutingRoot.kt
• ktor-server/ktor-server-tests/common/test/io/ktor/tests/server/sessions/SessionTest.kt

---

📝 Walkthrough

Walkthrough

After pipeline execution, routing now responds with the current response status if the call remains unhandled; added a test verifying that setting a session and only a response status emits a Set-Cookie header.

Changes

Cohort / File(s)	Summary
Routing execution logic ktor-server/ktor-server-core/common/src/io/ktor/server/routing/RoutingRoot.kt	After routingCallPipeline.execute(...) completes successfully, if the call is still unhandled, check response.status() and invoke respond(status) to send that status.
Session tests ktor-server/ktor-server-tests/common/test/io/ktor/tests/server/sessions/SessionTest.kt	Added test scoped session sends Set-Cookie header without explicit respond that sets a session and only response.status(...), asserting Set-Cookie is emitted and status is OK.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• PR #4938: Also modifies RoutingRoot.executeResult (changes around response/exception handling), touching the same function and closely related.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically references issue #5033 and describes the fix for scoped Sessions plugin not sending Set-Cookie without call.respond().
Description check	✅ Passed	The description follows the template with all required sections (Subsystem, Motivation, Solution) completed with relevant details about the issue and fix.
Linked Issues check	✅ Passed	The code changes directly address issue #5033 by ensuring respond() is called when a handler sets status without responding, enabling scoped sendPipeline interceptors to fire.
Out of Scope Changes check	✅ Passed	All changes are directly related to fixing the scoped Sessions plugin issue: routing logic modification and a test validating the fix with no unrelated changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

⚔️ Resolve merge conflicts

• Resolve merge conflict in branch fix-5033-scoped-session-cookie

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[zibet27]

Nice!

[zibet27]

Just a nitpick
I would use let instead of !! operator

if (!routingApplicationCall.isHandled) {
   routingApplicationCall.response.status()?.let { status ->
      routingApplicationCall.respond(status)
   }
}

[fru1tworld]

Good point, updated. Thanks for the review!

[zibet27]

LGTM
@fru1tworld Thank you for the fix!

PS: I'll rebase the branch to release/3.x, so it can be included in the next patch release. Or you can do it by running the switch-base-branch.sh script in the project root

[fru1tworld]

Rebased onto release/3.x using cherry-pick. Thanks for the review and the suggestion!