Claude/cpu guard script dn d8u

[gamblecodezcom]

User description

Summary by Sourcery

Improve robustness of endpoint startup, logging, and webhook handling.

Bug Fixes:

• Fallback to /tmp when endpoint log directory is not writable during production startup.
• Escape the project directory in the pkill pattern to reliably terminate existing backend node processes.
• Guard backend logger writes against destroyed or non-writable streams and handle stream write errors without crashing.
• Return HTTP 400 instead of 500 when the autofix webhook receives no raw body, avoiding unnecessary retries while still logging configuration issues.

Enhancements:

• Clarify autofix webhook error logging message to better describe raw-body middleware misconfiguration.

---

CodeAnt-AI Description

Improve endpoint startup resilience, logging safety, and webhook error responses

What Changed

• If endpoint log directory is not writable, logs are written to /tmp so the endpoint still starts and produces logs
• Logger avoids crashing when a log stream is closed or fails and will fall back to console output instead of terminating
• Autofix webhook returns HTTP 400 (Bad Request) when the raw request body is missing, preventing senders from retrying while still logging the configuration issue
• Service startup now clears any process holding the endpoint port using a graceful SIGTERM then SIGKILL if needed, preventing immediate crash/restart loops
• Process-kill commands reliably match the project path by escaping special characters so stale backend processes are terminated consistently

Impact

✅ Fewer endpoint crash/restart loops
✅ Endpoint logs available even when log directory is unwritable
✅ Clearer webhook errors and fewer unnecessary retries

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

Summary by CodeRabbit

• Bug Fixes

  • Fixed webhook error handling to return HTTP 400 when request body is missing instead of HTTP 500
  • Improved backend stream writing with robust error handling and logging

• Improvements

  • Service now gracefully terminates with timeout before force shutdown
  • Log file creation now handles failures gracefully with fallback paths
  • Extended service access permissions for additional writable directories

[codeant-ai]

CodeAnt AI is reviewing your PR.

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Improves robustness of endpoint startup and logging by making log file creation more fault-tolerant, making process-kill patterns safe for special characters in PROJECT_DIR, hardening backend logger stream writes, and returning a 400 instead of 500 when the autofix webhook body middleware is misconfigured so senders don’t retry indefinitely.

Sequence diagram for updated autofix webhook error handling

sequenceDiagram
    actor AutofixSender
    participant Backend
    participant Logger

    AutofixSender->>Backend: POST /autofix/webhook (payload, signature)
    Backend->>Backend: Extract req.rawBody
    alt rawBody missing or not Buffer
        Backend->>Logger: error(autofix.webhook, Missing rawBody — raw-body middleware did not run, { requestId })
        Backend-->>AutofixSender: 400 Bad Request (error: missing body)
    else rawBody present and signature valid
        Backend->>Backend: Process webhook normally
        Backend-->>AutofixSender: 200 OK
    else rawBody present but signature invalid
        Backend-->>AutofixSender: 401 Unauthorized
    end

Loading

Class diagram for updated backend logger stream handling

classDiagram
    class Logger {
        +info(scope, message, meta)
        +warn(scope, message, meta)
        +error(scope, message, meta)
        +_write(streams, obj)
    }

    class WritableStream {
        +writable : boolean
        +destroyed : boolean
        +write(chunk)
    }

    Logger : filters streams where s && !s.destroyed && s.writable
    Logger : iterates writable streams and calls write in try-catch
    Logger : falls back to console.log when no writable streams

    Logger --> WritableStream : writes log lines to

Loading

Flow diagram for prod-run endpoint startup and logging robustness

flowchart TD
    A[Start prod-run endpoint setup] --> B[Set ENDPOINT_LOG_DIR and file paths]
    B --> C[Try touch ENDPOINT_LOG and ENDPOINT_ERR]
    C -->|success| D[Keep configured log directory]
    C -->|failure| E[Warn cannot write to ENDPOINT_LOG_DIR]
    E --> F[Set ENDPOINT_LOG and ENDPOINT_ERR under /tmp]
    F --> G[Touch /tmp log files]
    D --> H{systemctl available?}
    G --> H
    H -->|yes| I[Try systemctl restart runewager-endpoint]
    I -->|success| J[Endpoint restarted via systemd]
    I -->|failure| K[Warn systemctl restart failed]
    K --> L[Escape PROJECT_DIR for regex and run pkill -f node .*_esc_dir/backend.js]
    L --> M[Sleep 1 and handle port checks]
    H -->|no| N[No systemd: direct nohup]
    N --> O[Escape PROJECT_DIR for regex and run pkill -f node .*_esc_dir/backend.js]
    O --> P[Sleep 1 and handle port checks]
    J --> Q[End]
    M --> Q
    P --> Q

Loading

File-Level Changes

Change	Details	Files
Make endpoint log file initialization robust to unwritable LOG_DIR by falling back to /tmp and warning the user.	Replace best-effort touch of backend.log/backend-error.log with a conditional that checks for failure On failure, emit a warning explaining that $ENDPOINT_LOG_DIR is not writable and that /tmp will be used instead Repoint ENDPOINT_LOG and ENDPOINT_ERR to /tmp paths and attempt to create those files as a fallback	prod-run.sh
Make pkill patterns safe when PROJECT_DIR contains regex special characters during endpoint restarts.	Introduce an escaped directory variable derived from PROJECT_DIR using sed to escape regex metacharacters Use the escaped directory variable inside the pkill -f pattern for both the systemd-fallback and non-systemd nohup restart paths	prod-run.sh
Harden backend logger to avoid crashing or misbehaving when output streams are closed or error on write.	Tighten the filter for writable streams to also exclude destroyed streams and require the writable flag Wrap stream.write calls in try/catch so individual stream failures are logged to stderr but do not break logging overall Preserve console logging fallback when no valid streams remain	backend.js
Change autofix webhook behavior when rawBody is missing so clients get a 400 instead of 500 while still logging a server-side configuration issue.	Adjust error log message to clarify that the raw-body middleware did not run rather than a generic misconfiguration Return HTTP 400 with a descriptive Bad request: missing body error instead of 500 to discourage retry storms from webhook senders	backend.js

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7c6debe and 4f3dd8a.

📒 Files selected for processing (4)

• backend.js
• prod-run.sh
• runewager-endpoint.service
• runewager.service

---

📝 Walkthrough

Walkthrough

This PR hardens system robustness through improved error handling in backend logging, graceful process termination in service startup, safer path handling in deployment scripts, and expanded service write permissions.

Changes

Cohort / File(s)	Summary
Backend Logging & Error Handling backend.js	Added strict stream validation before writes (checks destroyed/writable state) and wrapped write operations in try/catch guards. Improved autofix webhook error handling to return 400 with descriptive logging when raw request body is missing, instead of 500.
Deployment & Process Management prod-run.sh	Guarded log file creation with error handling; failures now redirect logs to /tmp with path updates. Escaped PROJECT_DIR in pkill patterns to safely handle special characters in process termination across both systemd-restart and fallback paths.
Service Startup Robustness runewager-endpoint.service	Replaced unconditional hard kill with graceful termination sequence: sends SIGTERM, waits 3 seconds, escalates to SIGKILL if needed. Prefers lsof for PID discovery with fuser fallback. Early exit if no stale PID found.
Service Permissions runewager.service	Extended ReadWritePaths directive to include /var/www/html/Runewager/qa, expanding writable directory permissions for the service.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Claude/cpu guard script dn d8u #121: Modifies backend.js and service scripts with similar error-handling and robustness improvements
• Claude/apply onboarding fixes r rf6 k #32: Touches prod-run.sh with overlapping startup/logging and process-handling enhancements
• Add admin view toggles, persistent admin dashboard, and lightweight /sshv VPS console; update .gitignore #72: Updates runewager.service ReadWritePaths configuration with similar permission management

Suggested labels

codex, size:M

Poem

🐰 Whiskers twitch with glee,
Errors caught gracefully,
Paths escape with care,
Processes terminate fair,
Robust systems everywhere! 🎉

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/cpu-guard-script-DnD8u

---

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

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The _esc_dir sed escaping pattern ([.[\*^$()+?{|]) is fragile (e.g., ] and - aren’t handled correctly and some chars after ] aren’t actually in the class); consider centralizing this into a small helper or using a more robust escape function so PROJECT_DIR values with regex metacharacters are always safe.
• The _esc_dir computation is duplicated in the two pkill branches in prod-run.sh; consider computing it once near where PROJECT_DIR is set or reusing a helper to keep the logic consistent and easier to maintain.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `_esc_dir` sed escaping pattern (`[.[\*^$()+?{|]`) is fragile (e.g., `]` and `-` aren’t handled correctly and some chars after `]` aren’t actually in the class); consider centralizing this into a small helper or using a more robust escape function so `PROJECT_DIR` values with regex metacharacters are always safe.
- The `_esc_dir` computation is duplicated in the two `pkill` branches in `prod-run.sh`; consider computing it once near where `PROJECT_DIR` is set or reusing a helper to keep the logic consistent and easier to maintain.

## Individual Comments

### Comment 1
<location path="prod-run.sh" line_range="405-407" />
<code_context>
 ENDPOINT_LOG="$ENDPOINT_LOG_DIR/backend.log"
 ENDPOINT_ERR="$ENDPOINT_LOG_DIR/backend-error.log"
-touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null || true
+if ! touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null; then
+    warn "Cannot write to $ENDPOINT_LOG_DIR — falling back to /tmp for endpoint logs"
+    ENDPOINT_LOG="/tmp/runewager-backend.log"
+    ENDPOINT_ERR="/tmp/runewager-backend-error.log"
+    touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" || true
+fi

</code_context>
<issue_to_address>
**suggestion:** Consider suppressing stderr and/or guarding the fallback touch to avoid noisy failures in /tmp

The fallback `touch` in `/tmp` isn’t redirected, so if `/tmp` is also unwritable (e.g., locked-down envs/chroots), it will start emitting errors to stderr and could behave differently under `set -e`. To preserve the original quiet, best‑effort behavior, consider something like:

```sh
touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null || true
```
for the fallback as well.

```suggestion
    ENDPOINT_LOG="/tmp/runewager-backend.log"
    ENDPOINT_ERR="/tmp/runewager-backend-error.log"
    touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null || true
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion: Consider suppressing stderr and/or guarding the fallback touch to avoid noisy failures in /tmp

The fallback touch in /tmp isn’t redirected, so if /tmp is also unwritable (e.g., locked-down envs/chroots), it will start emitting errors to stderr and could behave differently under set -e. To preserve the original quiet, best‑effort behavior, consider something like:

touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null || true

for the fallback as well.

Suggested change

	ENDPOINT_LOG="/tmp/runewager-backend.log"
	ENDPOINT_ERR="/tmp/runewager-backend-error.log"
	touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" || true
	ENDPOINT_LOG="/tmp/runewager-backend.log"
	ENDPOINT_ERR="/tmp/runewager-backend-error.log"
	touch "$ENDPOINT_LOG" "$ENDPOINT_ERR" 2>/dev/null || true

[codeant-ai]

Nitpicks 🔍

🔒 No security issues identified

⚡ Recommended areas for review Reliability The pkill pattern now escapes many regex metacharacters from PROJECT_DIR before using pkill -f. This is an improvement, but ensure the escape covers all characters that are meaningful to the regex engine used by pkill on target platforms; verify edge cases (spaces, newlines, unusual unicode) won't break the sed expression. Also confirm this approach behaves correctly when PROJECT_DIR is empty or extremely long. Operational Issue The script falls back to writing endpoint logs to /tmp if the project log directory is not writable. Logs in /tmp may be excluded from systemd ReadWritePaths, logrotate, and retention policies, and may be lost on reboot. Confirm fallback path is acceptable for production or ensure systemd units and logrotate are updated to include the fallback. Robustness The new logger write path filters streams by s && !s.destroyed && s.writable and then writes to each stream. This can still attempt writes to streams without a write function or miss backpressure (when s.write returns false). Repeated failing streams may be retried on every log call and could flood console/error paths. Consider stronger guards and removal/cleanup of failing streams, and handling write() backpressure or drain events. Behavior Change The autofix webhook now returns HTTP 400 when req.rawBody is missing (previously 500). This prevents retries from callers but also changes monitoring/alert semantics: a server-side middleware misconfiguration will look like a client bad request. Ensure operators are notified (metrics/alerts or admin DM) when this case occurs so misconfigurations don't go unnoticed.

[codeant-ai]

CodeAnt AI finished reviewing your PR.