[app] add worker instance

[capcom6]

Summary by CodeRabbit

• Infrastructure
  • Transitioned service deployment from staging to worker architecture with updated configuration
  • Modified deployment update strategy for improved service transition reliability
  • Enhanced network isolation for backend services

[coderabbitai]

Walkthrough

The pull request replaces the staging service with a worker service in compose.app.yml. Environment variables migrate from STAGING__* to BACKEND__DATABASE__* equivalents. The worker service is removed from the public network, which is now marked as external. Prometheus job labels update from backend to worker, and Traefik staging-specific routing is removed. The deployment update strategy changes from start-first to stop-first.

Changes

Cohort / File(s)

Summary

Service replacement and configuration compose.app.yml

Staging service renamed to worker; environment variables updated from STAGING__DATABASE__* to BACKEND__DATABASE__* format; HTTP__PROXIES removed from worker environment; worker service detached from public network; public network added as external resource; Prometheus job label updated to reflect worker service; Traefik routing and middleware configurations specific to staging removed; deployment update strategy changed from start-first to stop-first.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify all STAGING__* environment variable references are properly replaced with BACKEND__DATABASE__* equivalents
• Confirm networking configuration changes (public network external designation) do not break service connectivity
• Validate Prometheus scrape configuration with updated job label reflects the worker service correctly
• Check that removal of Traefik staging routes does not leave orphaned middleware or listener configurations

Possibly related PRs

• infra#2: Initial addition of backend service and BACKEND__DATABASE__ environment variables that this PR builds upon for the worker service configuration.
• infra#12: Earlier iteration replacing staging service with worker; this change appears to be a refinement or continuation of that work.

Pre-merge checks and finishing touches

❌ 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%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "[app] add worker instance" is directly related to the main changes in the changeset. The raw summary indicates that the primary modification is replacing the staging service with a worker service and updating its configuration across multiple aspects (environment variables, networking, deployment settings, and update/rollback behavior). The title accurately captures the core intent of introducing a worker service instance, uses clear and specific language that would be easily understood by someone scanning the commit history, and avoids vague terminology or unnecessary noise.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch app/add-worker

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 04667a8 and 9c5dd95.

📒 Files selected for processing (1)

• compose.app.yml (4 hunks)

🔇 Additional comments (3)

compose.app.yml (3)

100-106: Verify the rationale for the differing update strategies.

The worker service uses stop-first for both update_config and rollback_config, while the backend service uses start-first. This affects how services are upgraded: stop-first terminates the current instance before starting the new one (higher downtime risk), whereas start-first starts the new instance first (requires more resources but safer).

Please confirm this difference is intentional and aligns with your deployment requirements for a worker service vs. the backend HTTP service.

---

67-78: Clarify whether the worker intentionally excludes HTTP__PROXIES.

The worker service environment (lines 75–78) does not include the HTTP__PROXIES variable that is present in the backend service (line 8). This is a meaningful difference—if the worker needs outbound proxy support for external API calls or task processing, this omission could be a hidden defect. If the exclusion is intentional (e.g., worker operates only within the cluster), please document this assumption.

---

83-84: Verify that the public network is properly defined externally.

The worker service connects only to the internal network and no longer to the public network (line 84). The networks section (line 193) marks public as external: true. Confirm that the orchestration layer (Docker Swarm, Kubernetes, or equivalent) has already provisioned this network, and that the backend service (which still connects to both internal and public on lines 23–24) is compatible with this setup.

---

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.}