✨(scaling) enable horizontal scaling via optional Redis adapters - #85
✨(scaling) enable horizontal scaling via optional Redis adapters#85Nastaliss wants to merge 3 commits into
Conversation
📝 WalkthroughWalkthroughAdds optional Redis-backed session and Socket.io sharing for horizontally scaled production instances, updates share/invite UI behavior and translations, removes unused client state and props, and changes a folder preference fallback. ChangesHorizontal scaling
Share UI behavior
Cleanup and compatibility
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant ProductionConfig
participant ProjectInstance
participant Redis
participant SocketClients
ProductionConfig->>ProjectInstance: Configure Redis adapters from REDIS_URL
ProjectInstance->>Redis: Store and retrieve shared sessions
ProjectInstance->>Redis: Publish Socket.io broadcasts
Redis->>ProjectInstance: Deliver broadcasts to instances
ProjectInstance->>SocketClients: Emit realtime events
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@docker-compose.yml`:
- Around line 57-62: Update the projects service port configuration to support
the documented horizontal scaling flow without binding every replica to the
fixed host port 3000. Use dynamic publishing or an explicit host port range, or
revise the scaling documentation to require an external load balancer targeting
container port 1337; keep container port 1337 exposed.
- Around line 129-139: Update the projects service’s depends_on block to include
redis with condition service_healthy alongside postgres, ensuring startup waits
for Redis readiness when the Redis service is enabled. Preserve the existing
postgres dependency and the commented Redis service configuration.
In `@ENVIRONMENT_VARIABLES.md`:
- Around line 66-75: Document that all production replicas using REDIS_URL must
share the same SECRET_KEY so Sails can validate session cookies across
instances. Update ENVIRONMENT_VARIABLES.md lines 66-75 with this requirement,
and add the same note or a reference to the shared required secret in
server/.env.sample lines 43-49.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 68c13d37-6fa3-4e96-9c14-b1433557b376
⛔ Files ignored due to path filters (1)
server/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
ENVIRONMENT_VARIABLES.mddocker-compose.ymlserver/.env.sampleserver/config/env/production.jsserver/package.json
| # Only needed for horizontal scaling (see REDIS_URL above). Uncomment to run | ||
| # several `projects` instances that share sessions and realtime broadcasts. | ||
| # redis: | ||
| # image: redis:7-alpine | ||
| # restart: on-failure | ||
| # healthcheck: | ||
| # test: ['CMD', 'redis-cli', 'ping'] | ||
| # interval: 10s | ||
| # timeout: 5s | ||
| # retries: 5 | ||
|
|
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- docker-compose.yml relevant sections ---\n'
if [ -f docker-compose.yml ]; then
nl -ba docker-compose.yml | sed -n '1,220p'
else
echo 'docker-compose.yml not found'
fi
printf '\n--- docker compose depends_on health references ---\n'
rg -n "redis|depends_on|healthcheck|service_healthy|projects|postgres|postgresql" docker-compose.yml || trueRepository: suitenumerique/projects
Length of output: 252
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- docker-compose.yml relevant sections ---'
if [ -f docker-compose.yml ]; then
nl -ba docker-compose.yml | sed -n '1,220p'
else
echo 'docker-compose.yml not found'
fi
printf '%s\n' ''
printf '%s\n' '--- docker compose depends_on health references ---'
rg -n "redis|depends_on|healthcheck|service_healthy|projects|postgres|postgresql" docker-compose.yml || trueRepository: suitenumerique/projects
Length of output: 246
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- docker-compose.yml relevant sections ---'
if [ -f docker-compose.yml ]; then
awk '{printf "%5d %s\n", NR, $0}' docker-compose.yml | sed -n '1,220p'
else
echo 'docker-compose.yml not found'
fi
printf '%s\n' ''
printf '%s\n' '--- docker compose depends_on health references ---'
grep -nE 'redis|depends_on|healthcheck|service_healthy|projects|postgres|postgresql|REDIS_URL' docker-compose.yml || trueRepository: suitenumerique/projects
Length of output: 7210
🌐 Web query:
Docker Compose depends_on condition service_healthy documentation startup order healthcheck
💡 Result:
In Docker Compose, the depends_on attribute controls the order in which services are started and stopped [1][2]. By default, using the short syntax (a simple list of service names) only guarantees that a dependency container has been created and started, not that the application inside it is ready to accept connections [1][2][3]. To ensure a service does not start until a dependency is fully ready, you must use the depends_on long syntax in combination with a healthcheck definition [2][4]. ### Implementation 1. Define a healthcheck in the dependency service: This specifies a command that Docker periodically executes to determine the service's "health" [4][3]. 2. Use the long syntax for depends_on in the dependent service: Set the condition field to service_healthy [1][5]. ### Example Configuration yaml services: db: image: postgres:18 healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 start_period: 30s web: build: . depends_on: db: condition: service_healthy ### Key Concepts * service_started: The default behavior; waits for the container to start [1][3]. * service_healthy: Docker Compose waits until the dependency's healthcheck passes (returns a status of "healthy") before starting the dependent service [1][2][5]. * service_completed_successfully: Useful for one-off tasks (like database migrations); waits for the dependency to run and exit with a status code of 0 [1][3]. By requiring service_healthy, you prevent race conditions where a dependent application attempts to connect to a service that is still initializing [4][3]. Always consider including a start_period within your healthcheck to allow sufficient time for services with long startup processes to initialize before the first healthcheck failure is recorded [2].
Citations:
- 1: https://docs.docker.com/reference/compose-file/services/
- 2: https://docs.docker.com/compose/how-tos/startup-order/
- 3: https://paulund.co.uk/notebook/docker/docker-compose-healthchecks
- 4: https://www.luisllamas.es/en/docker-compose-depends-on-healthchecks/
- 5: https://github.com/compose-spec/compose-spec/blob/e8db8022c0b2e3d5eb007d629ff684cbe49a17a4/spec.md
🌐 Web query:
Kubernetes official 100-day code of the day "100daysofk8s" Redis Postgres StatefulSet Deployment initContainer 100-day
💡 Result:
The hashtag #100daysofk8s refers to a popular community-driven learning challenge where participants document their journey of learning Kubernetes over 100 days [1][2][3][4]. While there is no single official curriculum, many learners use this initiative to deep-dive into core Kubernetes concepts, including Deployments, StatefulSets, and the use of initContainers for configuring stateful applications like Redis and PostgreSQL [5][1][6][7]. StatefulSets are the recommended Kubernetes controller for applications that require stable network identities, persistent storage, and ordered deployment/scaling [8][9][7]. Unlike Deployments, which are typically used for stateless applications, StatefulSets assign a sticky, unique identity (an ordinal index) to each Pod [8][7]. Key concepts often explored in this context include: StatefulSets vs. Deployments: While Deployments manage stateless replicas that are interchangeable, StatefulSets manage Pods with persistent storage and unique identifiers (e.g., redis-0, redis-1), making them essential for databases like PostgreSQL and Redis [8][9][7]. InitContainers: These are often used in StatefulSets to perform setup tasks before the main application starts [6]. For example, in a Redis cluster, an initContainer might examine the Pod's ordinal index to determine if it should configure itself as a master or a replica [6][10]. Persistent Storage: StatefulSets utilize volumeClaimTemplates to ensure that each Pod in the set receives its own dedicated PersistentVolume (PV), preventing data loss and ensuring persistence across Pod rescheduling [8][9][7]. If you are following a #100daysofk8s journey, common practical projects include deploying a PostgreSQL database with persistent storage [11][5] or setting up a Redis cluster where initContainers automate the configuration of nodes based on their unique identities [6][10].
Citations:
- 1: https://www.linkedin.com/posts/vembut_100daysofk8s-day15-kubernetes-activity-7345451085861441537-5smp
- 2: https://www.linkedin.com/posts/musta-shaik_100days-kubernetes-kubernetes-activity-7412794543995072512-BhJ5
- 3: https://www.linkedin.com/posts/yevhenii-padafa_the-linux-foundation-linkedin-activity-6981232453348691968-G6AQ
- 4: https://www.linkedin.com/posts/premasai-m-s-b98311197_kubernetes-minikube-100daysofk8s-activity-7245273505011769344-37Ag
- 5: https://www.linkedin.com/posts/akarjun313_kubernetes-docker-backenddevelopment-activity-7327720073509371905-FVAC
- 6: https://oneuptime.com/blog/post/2026-01-06-kubernetes-stateful-applications-postgres-redis-kafka/view
- 7: https://www.sysdig.com/learn-cloud-native/kubernetes-statefulsets-overview
- 8: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
- 9: https://portworx.com/knowledge-hub/understanding-statefulsets-in-kubernetes/
- 10: https://www.crunchydata.com/blog/deploying-postgresql-clusters-kubernetes-statefulsets
- 11: https://www.linkedin.com/posts/er-swapnil-pawar_deploying-gogs-and-postgres-on-k8s-with-persistent-activity-7306336032763924481-ZRy_
Wire Redis readiness into projects startup ordering.
When the Redis service is uncommented for horizontal scaling, projects only declares a healthy Postgres dependency, so Redis can still be unavailable at startup. Add redis: condition: service_healthy to the projects.depends_on block alongside postgres.
🤖 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 `@docker-compose.yml` around lines 129 - 139, Update the projects service’s
depends_on block to include redis with condition service_healthy alongside
postgres, ensuring startup waits for Redis readiness when the Redis service is
enabled. Preserve the existing postgres dependency and the commented Redis
service configuration.
7c01d3b to
bf12db7
Compare
bf12db7 to
23eba8e
Compare
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 `@docker-compose.yml`:
- Around line 58-61: The scaling documentation is inconsistent about the
load-balancer endpoint. Update the guidance at docker-compose.yml lines 58-61
and ENVIRONMENT_VARIABLES.md line 70 to consistently state whether the load
balancer reaches the Docker host through port 3000 or joins the Compose network
and routes to projects:1337; document the actual topology used by this Compose
setup without implying that both endpoints are interchangeable.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 9ce98480-9e93-44d7-9805-576eed88e197
📒 Files selected for processing (6)
ENVIRONMENT_VARIABLES.mdclient/patches/@gouvfr-lasuite+ui-kit+0.19.10.patchclient/patches/@gouvfr-lasuite+ui-kit+0.19.8.patchdocker-compose.ymlserver/.env.sampleserver/api/helpers/user-board-preferences/upsert-one.js
💤 Files with no reviewable changes (1)
- client/patches/@gouvfr-lasuite+ui-kit+0.19.8.patch
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 `@client/src/components/BoardActions/BoardActions.jsx`:
- Line 55: Remove the unused useState hook and its setter from BoardActions.
Update the popover’s onOpenChange usage to omit the prop when supported;
otherwise provide a stable no-op callback without retaining local state.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 37ea5b74-101d-417c-b207-c279e152645f
📒 Files selected for processing (6)
ENVIRONMENT_VARIABLES.mdclient/src/components/BoardActions/BoardActions.jsxclient/src/components/BoardTree/BoardTreeItem/BoardTreeItem.jsxclient/src/steps/BoardActionsStep/BoardActionsStep.jsxclient/src/steps/NotificationsStep/NotificationsStep.jsxdocker-compose.yml
💤 Files with no reviewable changes (2)
- client/src/steps/NotificationsStep/NotificationsStep.jsx
- client/src/components/BoardTree/BoardTreeItem/BoardTreeItem.jsx
4876492 to
0325177
Compare
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 `@docker-compose.yml`:
- Line 69: Set NODE_ENV=production in the relevant Docker Compose service
environment, alongside the commented REDIS_URL configuration, so production
settings load correctly before enabling Redis scaling.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 2a96d56e-9d03-4d42-8d1e-c356bf3e99dd
📒 Files selected for processing (6)
ENVIRONMENT_VARIABLES.mdclient/src/components/BoardActions/BoardActions.jsxclient/src/components/BoardTree/BoardTreeItem/BoardTreeItem.jsxclient/src/steps/BoardActionsStep/BoardActionsStep.jsxclient/src/steps/NotificationsStep/NotificationsStep.jsxdocker-compose.yml
💤 Files with no reviewable changes (3)
- client/src/components/BoardActions/BoardActions.jsx
- client/src/steps/NotificationsStep/NotificationsStep.jsx
- client/src/components/BoardTree/BoardTreeItem/BoardTreeItem.jsx
Summary by CodeRabbit