Rashin console: Skills tab stuck on "Reading agent skills…" forever; WebKit renderer busy-loops regardless of cache/backend state

Open
  • Is something wrong?
#858 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript
Domain
frontend

Research direction

The stuck state lives in the shipped bundle assets/index-CH5Z7SGl.js: the Skills tab's q() loader awaits Bt.hermesSkills() and the cached y4() wrapper of Bt.harnesses() via Promise.allSettled, so start at that loader and the $effect/derived store reading s.categories. Reproduce in a dev build that forces WebKit enable-developer-extras, attach the inspector and watch which effect re-runs on mount; if Svelte source is available, read that component rather than the minified file. Done looks like the Skills tab rendering categories while the WebKitWebProcess CPU returns to idle after mount.

Written by the indexing model from the issue text.

Description

area:ryoku needs-info type:bug

Symptom

Opening the console's Skills tab (rashin-app, http://127.0.0.1:3600) shows "Reading agent skills…" and never resolves — not after restarting the app, not after using its own in-tab refresh button, not after any amount of waiting. Predates the most recent ryoku-rashin/ryoku-desktop update (1.0.7 → 1.0.9).

Backend is healthy — ruled out as the cause

  • GET /api/hermes/skills and GET /api/harnesses (the two calls the tab's Promise.allSettled awaits) both return correct data in 2-8ms, tested repeatedly, including while the tab was stuck.
  • Fully wiped ~/.cache/rashin-app/WebKitCache, ~/.cache/rashin-app/CacheStorage, and ~/.local/share/rashin-app/localstorage/http_127.0.0.1_3600.*, then restarted on a fully cold process — identical failure reproduced within ~20-30 seconds. Rules out stale cache or corrupted localStorage.

Actual observed behavior

The page's sandboxed WebKitWebProcess (the renderer for the 127.0.0.1:3600 origin — a separate OS process from the rashin-app UI shell) pegs at 50-77% sustained CPU from the moment the Skills tab mounts, in a tight scheduling loop (poll_schedule_timeout), on every freshly launched process regardless of cache state. This points to a client-side reactive-effect/lifecycle bug in the shipped bundle (assets/index-CH5Z7SGl.js, Svelte-based), not a data or network issue.

Where to look

The Skills-tab component's q() loader (calls Bt.hermesSkills() + a cached y4() wrapping Bt.harnesses(), combined via Promise.allSettled) and whatever $effect/derived store reruns around s.categories. Minified variable names made it impractical to pin the exact faulty line without a real debugger attached.

Live-debug attempt (inconclusive, noting for future reference)

Tried WebKitGTK's remote inspector (WEBKIT_INSPECTOR_SERVER=127.0.0.1:<port>); confirmed the env var takes effect and the port opens/LISTENs. Installed Epiphany as a WebKit-capable client since no other WebKit browser existed on the system. Both curl and Epiphany got nothing usable back (empty reply / "unable to load the website") — likely because rashin-app's WebView doesn't have enable-developer-extras enabled, so the remote inspector has no inspectable target even with the socket open. Getting real console/stack-trace output will need a debug build with that flag forced, or source access.

Repro

  1. Open the console.
  2. Open the Skills tab.
  3. Observe: content never appears, loading state persists indefinitely.
  4. Observe (for confirmation): CPU of the WebKitWebProcess child of rashin-app climbs immediately on tab mount and stays high (50-77%+), independent of whether the API backend answers instantly (it does) or whether cache/localStorage is empty (confirmed, doesn't change outcome).

Environment

  • ryoku-rashin 1:1.0.9.r6109.g08ff328-1 (also reproduces on the version prior to the 2026-11-14 update)
  • Arch Linux, Hyprland compositor
  • webkit2gtk-4.1 2.54.2-1
Dominant language
QML
Stars
1.9k
Forks
122
Avg merge
18h 45m
Merged PRs (30d)
124

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Ryoku-dev/ryoku

All issues in Ryoku-dev/ryoku

Similar issues

More Web Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.