Skip to content

docs: document the session name option for multiple sessions#1405

Open
harshagarwalnyu wants to merge 5 commits into
h3js:mainfrom
harshagarwalnyu:docs/session-name-option
Open

docs: document the session name option for multiple sessions#1405
harshagarwalnyu wants to merge 5 commits into
h3js:mainfrom
harshagarwalnyu:docs/session-name-option

Conversation

@harshagarwalnyu

@harshagarwalnyu harshagarwalnyu commented Jun 2, 2026

Copy link
Copy Markdown

Closes #969.

The session example already uses the name option (name: "my-session") but never explains what it does, and the ability to run multiple independent sessions isn't documented anywhere. #969 asks for exactly this.

This adds two things to docs/4.examples/handle-session.md:

  • A short explanation after the existing Options example: name sets the cookie (and the x-{name}-session header) and defaults to h3, which is why the earlier examples produce a cookie named h3.
  • A "Use Multiple Sessions" section showing that distinct names give you independent sessions stored in separate cookies, with a note that reusing a name reuses the same cookie.

Verified against the current SessionConfig on main (name?: string, default h3, also used to derive the x-{name}-session header). Docs only, no code changes.

Summary by CodeRabbit

  • Documentation
    • Stronger warning: password is required for session encryption; avoid hardcoding and load a strong (32+ character) secret from an environment variable.
    • Clarified session options: all are optional except password; name controls the session cookie and the derived request header (lowercased).
    • Added "Use Multiple Sessions" guidance: independent sessions with different name values can coexist; reusing a name shares the cookie (last-write-wins).

Review Change Stack

@harshagarwalnyu harshagarwalnyu requested a review from pi0 as a code owner June 2, 2026 09:03
Copilot AI review requested due to automatic review settings June 2, 2026 09:03
@coderabbitai

coderabbitai Bot commented Jun 2, 2026

Copy link
Copy Markdown

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6055606c-5adf-4d2f-9b5a-fc3db4c2e936

📥 Commits

Reviewing files that changed from the base of the PR and between 7567774 and e489811.

📒 Files selected for processing (1)
  • docs/4.examples/handle-session.md

📝 Walkthrough

Walkthrough

Documentation clarifies session options (only password required), explains how name selects the cookie and x-<name>-session header (default h3x-h3-session), and adds a "Use Multiple Sessions" section demonstrating two independent sessions (auth, flash) and a same-name cookie collision note.

Changes

Session documentation: Multiple sessions

Layer / File(s) Summary
Password encryption warning
docs/4.examples/handle-session.md
Adds a warning that password must be provided to encrypt sessions and recommends sourcing a strong secret from an environment variable rather than hardcoding.
Options and multiple sessions docs
docs/4.examples/handle-session.md
States only password is required, documents how name determines the cookie and matching x-<name>-session header (default h3x-h3-session), and adds a "Use Multiple Sessions" section with an example using separate auth and flash sessions plus a warning that identical name values reuse the same cookie (last write wins).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I nibble docs with tiny paws,

Two sessions hop without a cause,
Auth and flash each find their way,
Same-name cookies clash and sway,
Secrets kept safe, the night applauds.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically describes the main change: documenting the session name option for multiple sessions, which is exactly what this PR accomplishes.
Linked Issues check ✅ Passed The PR fully addresses issue #969 by documenting that useSession accepts a name option, explaining how distinct names create independent sessions, clarifying that name determines the cookie and x-{name}-session header pattern, and showing practical examples.
Out of Scope Changes check ✅ Passed All changes are scoped to documenting the session name option and multiple sessions feature as requested in #969; no code modifications or unrelated documentation changes are included.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Warning

Review ran into problems

🔥 Problems

Git: Failed to clone repository. Please run the @coderabbitai full review command to re-trigger a full review. If the issue persists, set path_filters to include or exclude specific files.


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

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

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds documentation explaining session option defaults and demonstrates how to use multiple independent sessions in the same request.

Changes:

  • Clarifies that all session options are optional except password, and explains the name option’s impact on cookie/header naming.
  • Adds an example showing two independent sessions (auth and flash) coexisting without overwriting each other.
  • Adds a note warning that sessions sharing a name share the same cookie and will overwrite.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread docs/4.examples/handle-session.md Outdated
});
```

Every option is optional except `password`. The `name` option is worth calling out: it sets the cookie (and the `x-{name}-session` header) used to store the session, and defaults to `h3`. That default is why the earlier examples set a cookie named `h3`.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 1924aa6. That line now reads x-<name>-session and ties it to the concrete x-h3-session header the earlier examples produce, so it can no longer be misread as a literal header name.

app.use(async (event) => {
const auth = await useSession(event, {
name: "auth",
password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 7567774. Every example on this page deliberately shares one literal password so the snippets stay copy-paste consistent, so instead of swapping just these two lines (which would leave them out of step with the five identical literals above), I expanded the password > [!WARNING] at the top of the page. It now says the hardcoded value is only for readability and that a real app should load it from process.env.SESSION_PASSWORD, keep it a strong secret of at least 32 characters, and never commit it. That covers the copy-paste-to-production risk for every example at once.


const flash = await useSession(event, {
name: "flash",
password: "80d42cfb-1cd2-462c-8f17-e3237d9027e9",

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 7567774. Every example on this page deliberately shares one literal password so the snippets stay copy-paste consistent, so instead of swapping just these two lines (which would leave them out of step with the five identical literals above), I expanded the password > [!WARNING] at the top of the page. It now says the hardcoded value is only for readability and that a real app should load it from process.env.SESSION_PASSWORD, keep it a strong secret of at least 32 characters, and never commit it. That covers the copy-paste-to-production risk for every example at once.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
docs/4.examples/handle-session.md (1)

137-137: ⚡ Quick win

Clarify header name normalization for name.

Line 137: the implementation lowercases the derived header key (x-${name.toLowerCase()}-session). Consider noting this explicitly so mixed-case name values don’t cause confusion when users inspect/request headers.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/4.examples/handle-session.md` at line 137, Update the docs to explicitly
state that the session header is normalized to lowercase by the implementation:
the header is constructed as `x-${name.toLowerCase()}-session`, so if a user
supplies a mixed-case `name` value the header key seen in requests/responses
will be lowercased; reference the `name` option and the derived header format
`x-${name.toLowerCase()}-session` so readers understand header normalization and
avoid confusion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@docs/4.examples/handle-session.md`:
- Line 137: Update the docs to explicitly state that the session header is
normalized to lowercase by the implementation: the header is constructed as
`x-${name.toLowerCase()}-session`, so if a user supplies a mixed-case `name`
value the header key seen in requests/responses will be lowercased; reference
the `name` option and the derived header format
`x-${name.toLowerCase()}-session` so readers understand header normalization and
avoid confusion.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b6df0a33-42c0-49cc-a4a2-7c9382da71a9

📥 Commits

Reviewing files that changed from the base of the PR and between 84244b4 and e62ab0d.

📒 Files selected for processing (1)
  • docs/4.examples/handle-session.md

@harshagarwalnyu

harshagarwalnyu commented Jun 3, 2026

Copy link
Copy Markdown
Author

Pushed a small fix for the header placeholder point: it now reads x-<name>-session and ties it to the concrete x-h3-session header already shown earlier in the same page, so it's clear it's a pattern rather than a literal header name.

On the password comments: I kept the literal password value on purpose to stay consistent with the rest of this page. Every existing example here (Initialize, Get Data, Add Data, Clear, Options) uses the same 80d42cfb-... literal, so swapping only the two new examples to process.env.SESSION_PASSWORD would make the file inconsistent, and converting all of them is out of scope for a docs PR that's just about the name option. Happy to do a follow-up that moves the whole page to an env-var placeholder + a "use a strong secret, don't commit it" note if you'd prefer that as a separate change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

session utils don't mention anything about the name in the config

2 participants