Update Dockerfile and wsgi.py to simplify waitress-serve command

[fakebizprez]

• Removed the '--call' option from the CMD instruction in both Dockerfile and wsgi.py for cleaner command usage.
• Updated usage instructions in wsgi.py to reflect the change in command syntax.

Summary by CodeRabbit

• Chores
  • Updated production server configuration documentation and examples. No functional changes or performance impact.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[greptile-apps]

Skipped: This PR does not contain any of your configured labels: (greptile)

[coderabbitai]

Walkthrough

The Dockerfile CMD instruction for waitress-serve was updated to use positional argument syntax (wsgi:app) instead of the --call flag, while maintaining all other parameters. Corresponding documentation in wsgi.py was updated to reflect this invocation pattern change.

Changes

Cohort / File(s)	Summary
Waitress-serve invocation syntax update Dockerfile, wsgi.py	Updated waitress-serve invocation from --call flag to positional argument syntax for specifying the WSGI application entrypoint. All other configuration parameters remain unchanged. Documentation examples synchronized with new syntax.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A hop and a skip, the syntax takes flight,
From --call to position, the invocation burns bright,
Waitress serves true with arguments lean,
The cleanest command we have ever seen! 🚀

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: removing the '--call' option from waitress-serve commands in both Dockerfile and wsgi.py to simplify the invocation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 05228de and 7381297.

📒 Files selected for processing (2)

• Dockerfile
• wsgi.py

🧰 Additional context used

📓 Path-based instructions (3)

{Dockerfile,docker-compose.yml}

📄 CodeRabbit inference engine (CLAUDE.md)

Use Docker Compose with ARM build support for deployment and include privileged mode, I2C device mounting, and /sys read-only access for hardware interaction

Files:

• Dockerfile

**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.py: Implement thread safety for global state (current_temp, current_humidity) as read-only from thread perspective, and use threading.Lock() for concurrent access to mutable shared state in WebhookService
Use Bearer token authentication via @require_token decorator on protected API endpoints, with 401 (missing header) vs 403 (invalid token) distinction
Implement sensor data quality with multiple readings, outlier filtering (removes min/max), CPU heat compensation formula, and cached readings accessed by multiple endpoints
Implement webhook reliability with alert cooldown (5 minutes between same alert type), exponential backoff retry logic (delay = initial_delay × 2^(attempt_number)), and configurable retry count (1-10) and timeout (5-120 seconds)
Implement Slack webhook notification formatting through WebhookService.send_slack_message() with proper JSON payload structure and thread-safe operations
Use Flask-RESTX namespace for defining OpenAPI/Swagger models with input validation constraints (e.g., retry_count 1-10, timeout 5-120 seconds) and cross-field validation functions
Implement sensor compensation with CPU heat factor 0.7 and -4°F correction in get_compensated_temperature(), taking 10 readings (5 from humidity + 5 from pressure sensors) with outlier filtering
Apply +4% correction to humidity readings with 3 readings and outlier filtering in get_humidity()
Use environment variables from .env file for configuration (LOG_FILE, BEARER_TOKEN, SLACK_WEBHOOK_URL, WEBHOOK_, ALERT_, STATUS_UPDATE_) managed through python-dotenv
Implement Flask routes for public endpoints (/, /docs, /health, /metrics) without authentication and protected endpoints (/api/temp, /api/raw, /api/verify-token, /api/webhook/) requiring Bearer token
Include /health endpoint for monitoring/load balancer compatibility and /metrics endpoint with psutil system stats support

Files:

• wsgi.py

**/wsgi.py

📄 CodeRabbit inference engine (CLAUDE.md)

Use waitress 2.1.2+ as production WSGI server instead of Flask development server

Files:

• wsgi.py

🧠 Learnings (2)

📓 Common learnings

Learnt from: CR
Repo: freightCognition/temp_monitor PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-03T19:06:09.139Z
Learning: Applies to **/wsgi.py : Use waitress 2.1.2+ as production WSGI server instead of Flask development server

📚 Learning: 2026-01-03T19:06:09.139Z

Learnt from: CR
Repo: freightCognition/temp_monitor PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-03T19:06:09.139Z
Learning: Applies to **/wsgi.py : Use waitress 2.1.2+ as production WSGI server instead of Flask development server

Applied to files:

• Dockerfile
• wsgi.py

🔇 Additional comments (2)

wsgi.py (2)

8-8: LGTM! Documentation updated to reflect correct syntax.

The command-line usage example correctly shows the positional argument syntax without the --call flag, matching the Dockerfile change.

---

11-11: LGTM! Docker Compose example aligned with Dockerfile.

The docker-compose.yml usage example is now consistent with the updated Dockerfile CMD instruction.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# Check the full Dockerfile to understand the context
git ls-files | grep -i dockerfile

Repository: freightCognition/temp_monitor

Length of output: 83

---

🏁 Script executed:

# Read the Dockerfile
cat -n Dockerfile | head -100

Repository: freightCognition/temp_monitor

Length of output: 1660

---

🏁 Script executed:

# Check for requirements.txt and waitress version
cat requirements.txt | grep -i waitress

Repository: freightCognition/temp_monitor

Length of output: 88

---

🏁 Script executed:

# Check for docker-compose.yml
git ls-files | grep -i docker-compose

Repository: freightCognition/temp_monitor

Length of output: 91

---

🏁 Script executed:

# Check docker-compose.yml for ARM build, privileged, I2C, /sys configuration
cat docker-compose.yml

Repository: freightCognition/temp_monitor

Length of output: 934

---

🏁 Script executed:

# Check wsgi.py to verify app object structure
cat wsgi.py

Repository: freightCognition/temp_monitor

Length of output: 1047

---

Add ARM build support to docker-compose.yml.

The waitress-serve syntax on line 43 is correct—positional argument for direct app reference is appropriate since wsgi:app references the app object directly (not a factory function). However, the docker-compose.yml is missing required ARM build support. Per coding guidelines, Docker Compose deployments must include ARM build specification for the target Raspberry Pi 4 platform. Add build.platforms: ["linux/arm/v7", "linux/arm64/v8"] to the temp-monitor service in docker-compose.yml to ensure proper multi-architecture builds.

🤖 Prompt for AI Agents

In Dockerfile around lines 43 to 43, the container run command is fine but the
docker-compose.yml is missing ARM build support for Raspberry Pi 4; open
docker-compose.yml and under the temp-monitor service add a build.platforms
entry with the two required platforms: ["linux/arm/v7","linux/arm64/v8"] so
docker-compose can perform multi-architecture builds for ARM and ARM64 targets.