fix(OPENFRAM-006-13): CU-86akdyq31 Reply-failure banner appends raw user text without truncation, risking oversized/garbled notification body - #55
Conversation
…out truncation, risking oversized/garbled notification body
![flamingo[bot]](https://avatars.githubusercontent.com/in/3426709?s=60&v=4){kind=small}
| /// the notification cleared the inline field, so this is the only copy left. | ||
| /// The echoed text is truncated so an unbounded reply cannot itself blow the | ||
| /// notification past the platform's body cap. | ||
| fn failed(&self, reason: &str) -> String { |
There was a problem hiding this comment.
🦩 🟠 Reply-failure banner appends raw user text without truncation, risking oversized/garbled notification body
In Action::failed (notification_actions.rs), the Action::Reply(text) arm now passes the reply text through a new private helper truncate_chars(text, ECHOED_REPLY_CHARS) before interpolating it into the failure banner body, instead of concatenating the raw text unbounded. Added ECHOED_REPLY_CHARS (500) as the char-count ceiling, mirroring the BODY_CHARS truncation spirit cited in the finding, and truncate_chars operates on char boundaries (not bytes) so multi-byte UTF-8 replies aren't split mid-codepoint, appending … when truncation occurs. Added a unit test a_failed_reply_truncates_an_oversized_echo verifying the echoed portion is bounded and the ellipsis is present. Risk: the exact truncation length (500 chars) is a judgment call not specified by the finding or referenced BODY_CHARS constant (which lives elsewhere and wasn't available to import/reuse here), so a reviewer may want to align it with the actual shared constant if one exists elsewhere in the codebase.
🤖 Prompt for AI agents
In src-tauri/src/notification_actions.rs around line 201, review and complete this code-review fix: Reply-failure banner appends raw user text without truncation, risking oversized/garbled notification body.
What the draft fix changed: In `Action::failed` (notification_actions.rs), the `Action::Reply(text)` arm now passes the reply text through a new private helper `truncate_chars(text, ECHOED_REPLY_CHARS)` before interpolating it into the failure banner body, instead of concatenating the raw `text` unbounded. Added `ECHOED_REPLY_CHARS` (500) as the char-count ceiling, mirroring the BODY_CHARS truncation spirit cited in the finding, and `truncate_chars` operates on `char` boundaries (not bytes) so multi-byte UTF-8 replies aren't split mid-codepoint, appending `…` when truncation occurs. Added a unit test `a_failed_reply_truncates_an_oversized_echo` verifying the echoed portion is bounded and the ellipsis is present. Risk: the exact truncation length (500 chars) is a judgment call not specified by the finding or referenced BODY_CHARS constant (which lives elsewhere and wasn't available to import/reuse here), so a reviewer may want to align it with the actual shared constant if one exists elsewhere in the codebase.
Verify the change is correct and complete; do not refactor unrelated code.
fix confidence: 🟡 80 medium — react 👍/👎 to teach the reviewer
flamingo
Bot
changed the title
Closes findings from rule OPENFRAM-006-13 — Reply-failure banner appends raw user text without truncation, risking oversized/garbled notification body.
Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.
src-tauri/src/notification_actions.rs:201What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.
Run: https://product-hub.flamingo.so/admin/code-review
Run id:
a07442c8-7c54-4c4f-ac5d-d96e3425fe4cMerging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.
ClickUp task: CU-86akdyq31 OpenFrame desktop windows activator fixes (6 PRs)