docs: add Hapvida M365 auth server deploy handoff#48
Conversation
📝 WalkthroughWalkthroughA new deployment handoff document establishes the complete setup and validation process for deploying a dedicated Workit auth server in Hapvida's OCI environment to support one-click Microsoft 365 OAuth login with read-only scopes, including Docker/Kubernetes templates, Entra configuration, validation checklist, and handoff requirements. ChangesHapvida M365 Auth Server Deployment Handoff
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a deployment handoff document for the Hapvida M365 Auth Server, outlining configuration, environment variables, and deployment manifests. Feedback points out a discrepancy in the Kubernetes deployment template, which defaults to two replicas despite the operational notes warning that in-memory session storage requires a single replica or sticky sessions to avoid authentication failures.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| name: workit-auth-server | ||
| namespace: hapvida-ai | ||
| spec: | ||
| replicas: 2 |
There was a problem hiding this comment.
The deployment template defaults to replicas: 2. However, as noted in Section 11 (Operational notes), the auth server stores session state in-memory, meaning multiple replicas without sticky sessions will cause authentication failures (e.g., if /m365/start and /m365/callback hit different pods). To ensure a safe out-of-the-box deployment, it is recommended to default the template to replicas: 1.
| replicas: 2 | |
| replicas: 1 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d403f7d59c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| name: workit-auth-server | ||
| namespace: hapvida-ai | ||
| spec: | ||
| replicas: 2 |
There was a problem hiding this comment.
This template is likely to be copied as-is, but the same document later notes that M365 sessions/tokens are stored in memory and that /m365/start, /m365/callback, and /token/{state} can hit different pods without sticky routing. With replicas: 2 and a normal non-sticky ingress, a user can create the session on one pod and then be redirected/callback to another pod that does not have that state, causing intermittent login failures. Make the template default to replicas: 1 or explicitly include sticky-session configuration here.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@docs/plans/2026-06-02-hapvida-m365-auth-server-deploy-handoff.md`:
- Line 219: The default replica count currently set to "replicas: 2" conflicts
with the note that sessions/tokens are stored in-memory; change the
deployment/template default to a single replica and add a clear note near the
"replicas" setting (and in the session-storage section) explaining that
in-memory sessions require either sticky sessions or an external session store
before scaling replicas >1; reference and update the "replicas" entry and the
session-storage/sessions or tokens documentation so readers know to switch to
sticky sessions or an external store (e.g., Redis) before raising replicas.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c740d17e-a6ec-4b27-bdc8-d9bf0a33d735
📒 Files selected for processing (1)
docs/plans/2026-06-02-hapvida-m365-auth-server-deploy-handoff.md
| name: workit-auth-server | ||
| namespace: hapvida-ai | ||
| spec: | ||
| replicas: 2 |
There was a problem hiding this comment.
Align default replica count with session-storage constraints.
The template default replicas: 2 conflicts with your own operational note that sessions/tokens are in-memory and safest first deploy is single replica unless sticky sessions are guaranteed. This can cause OAuth state/token retrieval to land on different pods and fail intermittently.
Suggested doc fix
- replicas: 2
+ replicas: 1 ## 6. Kubernetes/OCI deployment example
Use this as a template. Replace placeholders before applying.
+For initial rollout, keep `replicas: 1` unless ingress sticky sessions are enabled (or session state is externalized).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| replicas: 2 | |
| replicas: 1 |
| replicas: 2 | |
| ## 6. Kubernetes/OCI deployment example | |
| Use this as a template. Replace placeholders before applying. | |
| For initial rollout, keep `replicas: 1` unless ingress sticky sessions are enabled (or session state is externalized). |
🤖 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/plans/2026-06-02-hapvida-m365-auth-server-deploy-handoff.md` at line
219, The default replica count currently set to "replicas: 2" conflicts with the
note that sessions/tokens are stored in-memory; change the deployment/template
default to a single replica and add a clear note near the "replicas" setting
(and in the session-storage section) explaining that in-memory sessions require
either sticky sessions or an external session store before scaling replicas >1;
reference and update the "replicas" entry and the session-storage/sessions or
tokens documentation so readers know to switch to sticky sessions or an external
store (e.g., Redis) before raising replicas.
2 participants
Adds the full deploy-manager handoff for hosting the dedicated Hapvida M365 Workit auth server in OCI HV, including required Entra values, runtime envs, Kubernetes template, validation checklist, and the exact request Bernardo needs to answer.
Summary by CodeRabbit
Release Notes