feat: size the message cap to this device's records - #34
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 8 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. 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, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe PR adds device-specific SolidSyslog tunables for a 256-byte message cap and one address, wires them through CMake, increases the logging task stack allocation, and updates README and run-report values for the message-cap configuration. ChangesMessage Cap Configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 `@README.md`:
- Around line 19-24: Update the RAM-cost prose in the README to match the
generated authoritative measurement of RAM +1,956 B, or explicitly clarify that
the existing 1,536-byte figure is only a subcomponent of the total. Keep the
generated cost-table block unchanged.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: df3f93c7-8986-4ee3-afd0-601f06986daf
⛔ Files ignored due to path filters (2)
measurements/message-cap.csvis excluded by!**/*.csvmeasurements/stages.tsvis excluded by!**/*.tsv
📒 Files selected for processing (5)
CMakeLists.txtREADME.mdapp/AppConfig.happ/config/solid_syslog_tunables.hrun-report.md
SOLIDSYSLOG_MAX_MESSAGE_SIZE drops from the library's default of 2048 to 256. RFC 5424 section 6.1 says a receiver should accept 2048; over UDP, RFC 5426 section 3.2 guarantees only 480. This device's records are far shorter than either, so 256 stays well inside every guarantee and anything longer is truncated rather than dropped. Flash +6,032 B (unchanged) RAM +1,956 B (+1,520) Log stack +680 B (+664) The cost is all RAM, and not where it looks. Setting the cap made the log task overflow its stack outright: [device] FATAL: stack overflow in task log The record is built on the stack of whichever task calls Log, and the log seam was still at the FreeRTOS minimum it inherited from the baseline. Measured at 800 bytes used, so the seam grows to 2 KiB by the same two-fold rule everything else here uses. That is 1,536 bytes of stack allocation against a net rise of 1,520: the smaller cap and address pool give 16 back. Worth knowing, and not yet explained: the previous stage formatted and sent the same record on the same 512-byte stack and reported 136 bytes used, with no overflow and the record arriving intact. Introducing the tunables file is what moved the formatter onto the caller's stack. The failure was loud rather than silent — configCHECK_FOR_STACK_OVERFLOW is 2, with a hook — which is the only reason this is a paragraph and not a corruption bug. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
719742e to
b63fd21
Compare
Pull request
What this stage adds
SOLIDSYSLOG_MAX_MESSAGE_SIZE drops from the library's default of 2048 to 256.
RFC 5424 section 6.1 says a receiver should accept 2048; over UDP, RFC 5426
section 3.2 guarantees only 480. This device's records are far shorter than
either, so 256 stays well inside every guarantee and anything longer is truncated
rather than dropped.
Flash +6,032 B (unchanged)
RAM +1,956 B (+1,520)
Log stack +680 B (+664)
The cost is all RAM, and not where it looks. Setting the cap made the log task
overflow its stack outright:
[device] FATAL: stack overflow in task log
The record is built on the stack of whichever task calls Log, and the log seam
was still at the FreeRTOS minimum it inherited from the baseline. Measured at 800
bytes used, so the seam grows to 2 KiB by the same two-fold rule everything else
here uses. That is 1,536 bytes of stack allocation against a net rise of 1,520:
the smaller cap and address pool give 16 back.
Worth knowing, and not yet explained: the previous stage formatted and sent the
same record on the same 512-byte stack and reported 136 bytes used, with no
overflow and the record arriving intact. Introducing the tunables file is what
moved the formatter onto the caller's stack. The failure was loud rather than
silent — configCHECK_FOR_STACK_OVERFLOW is 2, with a hook — which is the only
reason this is a paragraph and not a corruption bug.
Files
Checklist
measurements/message-cap.csvcommitted.measurements/stages.tsv.python3 scripts/gen-cost-table.py../run.shgreen (build + QEMU + baseline self-check) —run-report.mdcommitted.Context for review: 7 of 21 sequential single-commit PRs replaying the integration on top of the Baseline root. Each lands green and reviewed before the next is built on it, because a change to an early commit would force every commit above it to be re-run and re-measured.
Summary by CodeRabbit
New Features
Performance
Documentation