test(viewer): search_view + memory_tab proptest surface (WBS-6.2 #435) - #442
Conversation
Adds `crates/sl-viewer/tests/properties_viewer_search_memory.rs` with
12 proptest properties pinning `search_view` and `memory_tab`
reductions:
* `search_view::build_query`:
* Each field's post-trim value is what gets serialized — padding
on either side of a field value does not change the output.
* `since` (and by symmetry every other optional field) appears
in the query iff its post-trim value is non-empty.
* The documented break-character set (` `, `,`, `#`, `&`,
`=`, `+`) is percent-encoded; safe ASCII alphanumerics pass
through unchanged.
* `limit=` is always present and equals the parsed input or the
documented `"50"` fallback when parsing fails.
* `search_view::advanced_filter_active_count`:
* `min_tokens` and `tags` count as 1 each when non-empty
(post-trim); 0 otherwise.
* `limit"=="50"` does not count; any other value does.
* Trim-invariant: padded inputs produce the same count.
* `memory_tab::to_wiki_page`:
* `session_id` and `title` are carried through unchanged.
* Deterministic: applying it twice to the same session yields the
same `MemoryWikiPage`.
* `memory_tab::all_wiki_pages_from_sessions`:
* Output length equals input length.
* Order matches input order (page `i` ↔ session `i`).
Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reached
Next review available in: 56 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
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 |
codeant-ai
Bot
added
the
size:L
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| let q = build_query(&since, &until, &model, &min_tokens, &tags, &limit); | ||
| let has_since = q.split('&').any(|kv| kv.starts_with("since=")); | ||
| prop_assert_eq!(has_since, !since.trim().is_empty()); |
There was a problem hiding this comment.
Suggestion: The test claims to verify the trimmed, encoded, exactly-once since parameter, but it only checks whether any component starts with since=. A duplicate parameter, an incorrect value, or an unencoded value would all pass. Parse the query components and assert that there is exactly one since entry whose value matches the trimmed and encoded input. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ Incorrect `since` filters can reach `GET /api/search`.
- ⚠️ Duplicate parameters may produce ambiguous daemon filtering.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_search_memory.rs
**Line:** 79:81
**Comment:**
*Api Mismatch: The test claims to verify the trimmed, encoded, exactly-once `since` parameter, but it only checks whether any component starts with `since=`. A duplicate parameter, an incorrect value, or an unencoded value would all pass. Parse the query components and assert that there is exactly one `since` entry whose value matches the trimmed and encoded input.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| for ch in input.chars() { | ||
| if [' ', ',', '#', '&', '=', '+'].contains(&ch) { | ||
| prop_assert!( | ||
| !model_part.contains(ch), | ||
| "raw character {ch:?} present in model value: {model_part:?}", | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
Suggestion: This property only checks that reserved characters are absent from the output and never verifies their required percent-encoded replacements or that the input content is preserved. An implementation that silently drops these characters or substitutes arbitrary text would pass, despite violating the documented encoding contract. Assert the exact encoded model value for every generated input. [incomplete implementation]
Severity Level: Major ⚠️
- ⚠️ Encoding regressions can silently discard model-filter content.
- ⚠️ Search query property gives false confidence.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_search_memory.rs
**Line:** 148:155
**Comment:**
*Incomplete Implementation: This property only checks that reserved characters are absent from the output and never verifies their required percent-encoded replacements or that the input content is preserved. An implementation that silently drops these characters or substitutes arbitrary text would pass, despite violating the documented encoding contract. Assert the exact encoded model value for every generated input.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| let body_changes_default = !min_tokens.trim().is_empty() || !tags.trim().is_empty() || body.trim() != "50"; | ||
| let body_changes_other = !min_tokens.trim().is_empty() || !tags.trim().is_empty() || body.trim() != "50"; | ||
| prop_assert_eq!(default_count < changed_count, body_changes_default && body_changes_other); |
There was a problem hiding this comment.
Suggestion: The expected condition is duplicated with the filter fields included in both cases. When min_tokens or tags is non-empty and body.trim() is 50, both calls produce the same count, but the right-hand side is still true, so this property fails for valid inputs. Compare only whether body differs from 50 when asserting that the count increases. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Property test fails for valid active-filter inputs.
- ⚠️ CI validation is blocked by a false assertion.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_search_memory.rs
**Line:** 220:222
**Comment:**
*Incorrect Condition Logic: The expected condition is duplicated with the filter fields included in both cases. When `min_tokens` or `tags` is non-empty and `body.trim()` is `50`, both calls produce the same count, but the right-hand side is still true, so this property fails for valid inputs. Compare only whether `body` differs from `50` when asserting that the count increases.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| let page = to_wiki_page(&session); | ||
| prop_assert_eq!(page.session_id, session.id); |
There was a problem hiding this comment.
Suggestion: The memory tests assert only copied metadata, page count/order, and repeatability. Because session_strategy creates sessions without messages, the four extractor outputs are effectively exercised only for empty input; a regression that returns incorrect intent, context, contract, or acceptance data for real session content would still pass all these properties. Generate sessions containing representative messages and assert the extracted fields as part of the helper contract. [incomplete implementation]
Severity Level: Major ⚠️
- ⚠️ Memory Wiki extraction regressions remain undetected.
- ⚠️ Intent, context, contract, acceptance outputs lack coverage.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_search_memory.rs
**Line:** 233:234
**Comment:**
*Incomplete Implementation: The memory tests assert only copied metadata, page count/order, and repeatability. Because `session_strategy` creates sessions without messages, the four extractor outputs are effectively exercised only for empty input; a regression that returns incorrect intent, context, contract, or acceptance data for real session content would still pass all these properties. Generate sessions containing representative messages and assert the extracted fields as part of the helper contract.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Code Review SummaryStatus: 4 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (4 files)
Fix these issues in Kilo Cloud Reviewed by step-3.7-flash · Input: 91.4K · Output: 18.9K · Cached: 446.1K |
User description
Summary
Adds
crates/sl-viewer/tests/properties_viewer_search_memory.rswith 12 proptest properties pinning thesearch_viewandmemory_tabpure-helper reductions (WBS-6.2 #435, redux after the operator closed the original PR due to merge conflicts with #433's timeline surface).search_view::build_query(4 properties) — trim-invariance, present-iff-nonempty, percent-encoding of,,#,&,=,+, always-limit=with parse-or-"50"fallback.search_view::advanced_filter_active_count(3 properties) — per-field count,"50"not counted, trim-invariance.memory_tab::to_wiki_page(3 properties) —session_id/titlecarried through, deterministic.memory_tab::all_wiki_pages_from_sessions(2 properties) — length matches input, order matches input.Validation
cargo test -p sl-viewer --test properties_viewer_search_memory --features "desktop parquet" --locked— 12 passedcargo clippy -p sl-viewer --test properties_viewer_search_memory --features "desktop parquet" --locked -- -D warnings— cleancargo fmt --all --check— cleanRebase status
This branch was rebased onto
origin/mainafter #433 (timeline) was merged. The05ebd116(timeline) commit was skipped bygit rebasebecause #433 was already merged intoorigin/main; onlye79c9d47(search/memory) remained to apply.CodeAnt-AI Description
Add property-based tests that verify viewer search queries and memory pages remain consistent across varied inputs
What Changed
50fallbackImpact
✅ Fewer regressions in viewer search filters✅ Consistent memory page ordering✅ Clearer validation of default search limits💡 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:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
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:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
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.