fix: eliminate stale or concurrent container interference#223
Conversation
|
Warning Review limit reached
More reviews will be available in 42 minutes and 8 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughThe pull request replaces the previous cgroup directory discovery mechanism (a filesystem walk under Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
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 `@src/bpm/acceptance/fixtures/test-server/handlers/cgroup_limits.go`:
- Around line 100-114: The `cgroup-path` query parameter is being concatenated
directly into the filesystem path without validation, creating a path traversal
vulnerability. Validate the `exactPath` variable by canonicalizing it using
filepath operations and enforcing that the resulting full path stays within the
`/sys/fs/cgroup` base directory before passing it to `readCgroupValue` function
calls for reading `memory.max` and `pids.max`. Return an appropriate error
response if the path attempts to escape the intended cgroup subtree.
🪄 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
Run ID: 3284a2f9-fff5-4e95-ab8c-6a2120362fe0
📒 Files selected for processing (4)
src/bpm/acceptance/bpm_acceptance_test.gosrc/bpm/acceptance/fixtures/test-server/handlers/cgroup_limits.gosrc/bpm/acceptance/fixtures/test-server/handlers/cgroup_limits_test.gosrc/bpm/acceptance/fixtures/test-server/main.go
Replace the name-based cgroup directory search (findCgroupDir) with an exact-path approach: a new /self-cgroup-path endpoint reads the test-server's own /proc/self/cgroup and returns the cgroup v2 unified-mode path. That path is unique per Docker container ID, so it can never match a stale scope from a previous run or a scope owned by a concurrent build on the same worker. The privileged observer's /cgroup-limits endpoint now accepts cgroup-path and reads memory.max / pids.max directly from that path — no filesystem walk needed. also fixed a problem where the unit tests were hanging because of a flag parsing issue
1c6375d to
d5f8a72
Compare
The CI build was usually failing but intermittently passing after #219. This was because 1) the vm's /sys/fs/cgroup gets mapped into containers wholesale these days and 2) there were some stale containers on a worker which when present met the test criteria of a container named test-server with 743MB.
Replace the name-based cgroup directory search (findCgroupDir) with an exact-path approach: a new /self-cgroup-path endpoint reads the test-server's own /proc/self/cgroup and returns the cgroup v2 unified-mode path. That path is unique per Docker container ID, so it can never match a stale scope from a previous run or a scope owned by a concurrent build on the same worker. The privileged observer's /cgroup-limits endpoint now accepts cgroup-path and reads memory.max / pids.max directly from that path — no filesystem walk needed.
also fixed a problem where the new unit tests for the test server were hanging because of a flag parsing issue