feat: buffer records and drain them on the service task - #35
Merged
Conversation
A circular buffer in front of the sender, and the service seam finally doing something: Log enqueues and returns, the service task drains and sends. The logging task stops waiting on the network. A FreeRTOS mutex makes the two sides safe on different tasks, which is what brings the FreeRtos platform into the build. Flash +6,788 B (+756) RAM +5,676 B (+3,720) Log stack +448 B (-232) Service +728 B (+728) The RAM is the ring plus a stack that moved. Sending left the log task — its high-water fell from 800 to 568 — and arrived on the service task, which had been idle at the FreeRTOS minimum and overflowed on the first run: [device] FATAL: stack overflow in task service Measured at 780 bytes, so the service seam grows to 2 KiB by the same two-fold rule. That is the model working: the stage that deepens a seam pays for it, and the baseline holds no spare capacity on its behalf. Both overflows this evening were loud and immediate. That is worth more than it sounds — a seam sized by guesswork rather than by measurement fails silently, and on a logger a silent failure is indistinguishable from nothing to say. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe example now uses a bounded, mutex-protected circular buffer for syslog records. A FreeRTOS service task periodically drains the buffer to the lwIP UDP sender, with updated task sizing, harness timing, build linkage, documentation, and measurement reports. ChangesBuffered syslog pipeline
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant LogTask
participant CircularBuffer
participant ServiceTask
participant UDP_Sender
LogTask->>CircularBuffer: enqueue log record
ServiceTask->>CircularBuffer: poll and drain
CircularBuffer->>UDP_Sender: provide queued record
ServiceTask->>UDP_Sender: transmit record
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 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 `@app/main.c`:
- Around line 69-73: Replace the fixed vTaskDelay after LogTask_EmitOnce with a
bounded wait for an explicit acknowledgement from SolidSyslog_Service or the
collector indicating the record was transmitted and received. Keep the existing
enqueue result logging, and ensure Measure_Report() runs only after
acknowledgement or the defined timeout so readiness cannot be inferred from
elapsed time alone.
🪄 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: ae15093b-0fdc-4b0b-87d6-3f6af05ba64b
⛔ Files ignored due to path filters (2)
measurements/buffered.csvis excluded by!**/*.csvmeasurements/stages.tsvis excluded by!**/*.tsv
📒 Files selected for processing (8)
CMakeLists.txtREADME.mdapp/AppConfig.happ/main.capp/syslog/Syslog.capp/tasks/LogTask.happ/tasks/ServiceTask.crun-report.md
This was referenced Aug 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request
What this stage adds
A circular buffer in front of the sender, and the service seam finally doing
something: Log enqueues and returns, the service task drains and sends. The
logging task stops waiting on the network. A FreeRTOS mutex makes the two sides
safe on different tasks, which is what brings the FreeRtos platform into the
build.
Flash +6,788 B (+756)
RAM +5,676 B (+3,720)
Log stack +448 B (-232)
Service +728 B (+728)
The RAM is the ring plus a stack that moved. Sending left the log task — its
high-water fell from 800 to 568 — and arrived on the service task, which had been
idle at the FreeRTOS minimum and overflowed on the first run:
[device] FATAL: stack overflow in task service
Measured at 780 bytes, so the service seam grows to 2 KiB by the same two-fold
rule. That is the model working: the stage that deepens a seam pays for it, and
the baseline holds no spare capacity on its behalf.
Both overflows this evening were loud and immediate. That is worth more than it
sounds — a seam sized by guesswork rather than by measurement fails silently, and
on a logger a silent failure is indistinguishable from nothing to say.
Files
Checklist
measurements/buffered.csvcommitted.measurements/stages.tsv.python3 scripts/gen-cost-table.py../run.shgreen (build + QEMU + baseline self-check) —run-report.mdcommitted.Context for review: 8 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
Improvements