fix(viewer): reactive corpus loading + raw-sessions tab + brand splash - #417
Conversation
The async corpus loader populates a single Signal<Vec<Session>> in App() via spawn_blocking. Earlier revisions piped that signal through use_effect (BundlesTab) and use_signal(move || ...) initializers (HistoryTimeline, MemoryWiki) before reading it from the rsx body. Both patterns snapshot the signal at mount, when sessions is still empty, so the tabs froze on 'No bundles' / empty rows forever even after discovery finished. Drop the indirection: each tab now reads ctx.0.read() directly in the component body, which Dioxus tracks as a reactive dependency. The async load now propagates into the visible UI without a manual resubscribe. Also adds a Raw Sessions tab (Tab::Corpus) that exposes the underlying Vec<Session> — corpus, id, title, message count, last activity — plus a Reload button that re-runs discovery on demand. Gives the user a 'feed it myself any data' affordance without a custom-path picker (FR-RAW-1, FR-RAW-2 deferred). The brand icon pipeline is re-applied at origin/main (was previously local-only): tab.icon() method, ICON_SVG_* constants, icon_svg() lookup, and dangerous_inner_html in the tab button. A new line icon (corpus.svg) joins the 8 existing tab icons. While here, cargo fmt --all re-aligned web_exports.rs to the canonical rustfmt form (125 lines, whitespace only).
The first commit on this branch fixed the empty-data reactivity bug, but
left the UX half-broken: when the async load_sessions call is still
running (minutes on a 13k-file codex corpus), every tab shows the same
'No sessions ingested yet' message. The user has no signal that the
app is working, just slow.
Add a DiscoveryState context that exposes (loading: bool, error:
Option<String>) at the App root. BundlesTab and CorpusTab now branch
on that:
- loading && bundles empty -> LoadingState skeleton ('Discovering
local session corpus…'). Same component the visual fixture path
uses so the operator gets a familiar skeleton, not a dead end.
- error && bundles empty -> ErrorState with a Reload button that
bumps ReloadTrigger, re-running the discovery effect.
- bundles empty (post-load)-> FirstRunEmpty (the existing CTA).
- otherwise -> real bundles.
Verification (this branch, head SHA 3847d226… before this commit):
cargo test -p sl-viewer --lib --all-features --locked -> 69 passed
cargo build --release -p sl-viewer --features desktop -> clean
binary string-table includes 'Discovering local session corpus'
and sl-loading-state CSS hook
Also keep an ignored corpus smoke test behind --ignored so a future
session can run a real Auto scan on demand without blocking lefthook
or CI.
The launch splash was plain 'SessionLedger / Viewer' text on a blank
panel — no brand recognition, no loading affordance, and the
caption duplicated the app name verbatim.
Replace it with a brand splash that ties to the rest of the asset
suite:
- Getta mascot (the brand scholar-keeper from
assets/brand/mascot/getta-base.svg) is now embedded at compile
time and rendered at 96x96 with a soft accent drop-shadow and a
2.4s vertical float animation. Uses dangerous_inner_html so the
inline SVG (with its Lab-Coat cobalt gradient body and amber live
ring) renders without an extra HTTP request.
- A 3-dot bouncing spinner (splash-spinner-bounce keyframes, 180ms
stagger) sits below the caption. role=progressbar + aria-label so
screen readers report the loading state.
- Caption changed from 'Viewer' to 'Session viewer' to make the
role clear at a glance.
The pre-existing splash-dismiss animation (1.2s delay, ease-out fade)
is preserved; the splash hold fixture still pins the splash for
visual regression capture.
Verification (post-install):
binary SHA-256 = a96dff7a…
binary string-table contains:
launch-splash-mascot, launch-splash-spinner, launch-splash-spinner-dot
progressbar, Loading viewer
getta-body / getta-light / getta-amber / getta-shadow gradient defs
🤖 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: 41 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 ignored due to path filters (1)
📒 Files selected for processing (7)
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:XL
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| // updates the session signal. The earlier `use_signal(move || ...)` | ||
| // wrapper only ran the closure once at mount, so the timeline stayed | ||
| // frozen on the (then-empty) initial value forever. | ||
| let entries = all_timeline_entries(&ctx.0.read()); |
There was a problem hiding this comment.
Suggestion: selected_idx is retained while entries is rebuilt from the newly loaded session vector. After discovery or reload changes the order or membership, the same index can select a different session, so the detail pane silently changes identity; if the new list is shorter, the selection also disappears. Track the selected session by stable ID or explicitly clear/reconcile the selection when the corpus changes. [stale reference]
Severity Level: Major ⚠️
- ⚠️ History selection can silently change session identity after reload.
- ⚠️ Removed sessions leave the detail pane unexpectedly empty.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/src/history_tab.rs
**Line:** 115:115
**Comment:**
*Stale Reference: `selected_idx` is retained while `entries` is rebuilt from the newly loaded session vector. After discovery or reload changes the order or membership, the same index can select a different session, so the detail pane silently changes identity; if the new list is shorter, the selection also disappears. Track the selected session by stable ID or explicitly clear/reconcile the selection when the corpus changes.
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| // change. Mirrors the HistoryTimeline fix — `use_signal(move || ...)` | ||
| // initializer only runs once at mount, so the previous code froze on | ||
| // the initial empty value. | ||
| let pages = all_wiki_pages_from_sessions(&ctx.0.read()); |
There was a problem hiding this comment.
Suggestion: Every render recomputes all four heuristic extractors for every session. Because this component also reads selected_idx, merely selecting or switching a page reruns the full corpus-wide derivation, which can make the UI sluggish or block rendering for the large local corpus described by the application. Cache the derived pages and invalidate them only when the session signal changes. [performance]
Severity Level: Major ⚠️
- ⚠️ Memory page selection repeats corpus-wide extraction work.
- ⚠️ Large local corpora can make the Memory tab sluggish.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/src/memory_tab.rs
**Line:** 66:66
**Comment:**
*Performance: Every render recomputes all four heuristic extractors for every session. Because this component also reads `selected_idx`, merely selecting or switching a page reruns the full corpus-wide derivation, which can make the UI sluggish or block rendering for the large local corpus described by the application. Cache the derived pages and invalidate them only when the session signal changes.
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
| Ok(load_sessions(&source)) | ||
| } | ||
| }; | ||
| loading_signal.set(false); |
There was a problem hiding this comment.
Suggestion: Each reload starts an independent discovery task, but completion is not associated with the reload that started it. A slower earlier task can execute this line after a newer reload, setting loading to false while the newer scan is still running and allowing stale results or errors to overwrite the newer state. Track a generation number and ignore results from obsolete tasks, or cancel the previous task before starting another. [race condition]
Severity Level: Major ⚠️
- ❌ Reloaded corpus can be replaced by stale discovery results.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/src/app.rs
**Line:** 329:329
**Comment:**
*Race Condition: Each reload starts an independent discovery task, but completion is not associated with the reload that started it. A slower earlier task can execute this line after a newer reload, setting `loading` to false while the newer scan is still running and allowing stale results or errors to overwrite the newer state. Track a generation number and ignore results from obsolete tasks, or cancel the previous task before starting another.
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| ts_ms, | ||
| .collect() | ||
| } else if let Some(map) = value.get("mapping").and_then(|m| m.as_object()) { | ||
| map.values() |
There was a problem hiding this comment.
Suggestion: The mapping object is flattened using map.values(), whose order is based on JSON object-key iteration rather than the conversation's parent/child or chronological order. This makes the message vector scrambled for normal opaque node IDs; HistoryTimeline uses the first messages for previews and the last message for unfinished-state detection, so imported conversations can display incorrect previews and completion status. Follow the mapping parent chain or sort by the source timestamps before constructing the session. [logic error]
Severity Level: Major ⚠️
- ❌ Imported transcript previews can show wrong messages.
- ⚠️ Completion detection can inspect the wrong final message.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/src/web_exports.rs
**Line:** 192:192
**Comment:**
*Logic Error: The mapping object is flattened using `map.values()`, whose order is based on JSON object-key iteration rather than the conversation's parent/child or chronological order. This makes the message vector scrambled for normal opaque node IDs; `HistoryTimeline` uses the first messages for previews and the last message for unfinished-state detection, so imported conversations can display incorrect previews and completion status. Follow the mapping parent chain or sort by the source timestamps before constructing the session.
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| _ => String::new(), | ||
| }) | ||
| .unwrap_or_default(); | ||
| let ts_ms = msg.get("create_time").and_then(|v| v.as_f64().map(|f| f as i64)); |
There was a problem hiding this comment.
Suggestion: Message::ts_ms is defined as Unix milliseconds, but ChatGPT mapping exports use create_time in Unix seconds. Storing the seconds value directly makes imported timestamps about one thousand times too small, causing dates to render near 1970 and making activity comparisons against native millisecond timestamps incorrect. Convert the vendor value from seconds to milliseconds before assigning it. [logic error]
Severity Level: Major ⚠️
- ❌ Imported activity dates render near 1970.
- ⚠️ Raw Sessions sorting uses incorrect timestamps.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/src/web_exports.rs
**Line:** 214:214
**Comment:**
*Logic Error: `Message::ts_ms` is defined as Unix milliseconds, but ChatGPT mapping exports use `create_time` in Unix seconds. Storing the seconds value directly makes imported timestamps about one thousand times too small, causing dates to render near 1970 and making activity comparisons against native millisecond timestamps incorrect. Convert the vendor value from seconds to milliseconds before assigning it.
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
User description
What
Three commits on `fix/viewer-data-flow-unblock-20260805` that together fix the
"every page has no data" complaint, expose the underlying corpus, and put a
brand on the launch splash.
`198a210` — fix(viewer): reactive corpus loading + raw-sessions tab
The async `load_sessions` populates one `Signal<Vec>` at the App
root. Three tab components (`BundlesTab` via `use_effect` + separate
`bundles` signal; `HistoryTimeline` and `MemoryWiki` via `use_signal(move
|| ...)` initializers) snapshotted that signal at mount, when it was still
empty. The async load later updated the signal but those tabs never
re-evaluated, so they froze on "No bundles" / empty rows forever.
Drop the indirection: each tab now reads `ctx.0.read()` directly in the
component body, which Dioxus 0.6 tracks as a reactive dependency. Adds
`Tab::Corpus` (Raw Sessions) that exposes the underlying `Vec>
with corpus / id / title / message count / last activity, plus a Reload
button that re-runs discovery on demand. Also adds the brand icon
pipeline at origin/main (`Tab::icon()`, `ICON_SVG_*` constants,
`icon_svg()` lookup, `dangerous_inner_html` in the tab button) and
`assets/icons/line/corpus.svg`.
`335dcba` — feat(viewer): add loading + error states for long corpus discovery
The first commit fixed the reactivity but the full `DataSource::Auto`
scan touches 13k+ files and takes minutes on real hardware, so the user
has no signal that the app is working — just slow. Adds a
`DiscoveryState` context that exposes `(loading: bool, error: Option)`
at the App root. `BundlesTab` and `CorpusTab` branch on it:
local session corpus…").
`6c9a623` — feat(viewer): brand splash with mascot + animated loading dots
The launch splash was plain "SessionLedger / Viewer" text on a blank
panel. Replace with a brand splash that ties to the rest of the asset
suite:
compile time, rendered at 96×96 with a soft accent drop-shadow
and a 2.4s vertical float.
`role=progressbar` + `aria-label`.
Why
The user reported:
now fixed.
`Tab::Corpus`.
looks weak/poor and has no loading skeleton/circle or similar nor our
branding icons" — replaced with the brand splash.
Verification
pre-existing warnings (`App` snake_case, `default_subdir` dead code).
Sessions`, `Reload discovery`, `Discovering local session corpus`,
`launch-splash-mascot`, `launch-splash-spinner`, `getta-body` /
`getta-light` / `getta-amber` / `getta-shadow` gradient defs.
`http://127.0.0.1:8080/api/stream\` (matches the running sl-daemon).
Out of scope (left for follow-up)
only parses `.jsonl`). FR-RAW-3.
source; a path picker would be FR-RAW-2.
"desktop")]` / `#[cfg(feature = "web")]` (test target compiles both
features).
Test plan for reviewer
cargo test -p sl-viewer --lib --all-features --locked
cargo build --release -p sl-viewer --features desktop
cargo run -p sl-viewer --release
With sl-daemon running on 127.0.0.1:8080
Click through Bundles / History / Memory / Unfinished / Timeline / Corpus
to see real session data
Click the Raw Sessions tab; click "Reload discovery" to re-run
CodeAnt-AI Description
Make corpus discovery visible and expose raw sessions in the viewer
What Changed
Impact
✅ Fewer empty viewer tabs after startup✅ Clearer progress and retry feedback during corpus scans✅ Direct visibility into discovered local sessions💡 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.