docs: close KI-175, the Data Apps viewer hang on the demo stack

platform/explore/apps/access-and-data.md

@@ -102,7 +102,6 @@ The `subprocess` launcher runs every app process inside the Egret container as t
 
 - There is no public sharing and no embedding.
 - A shared-in user who is not a workspace member has no list to find the app from.
-- On the demo stack, viewers' apps stop opening (they stay on *Starting the app…*) about five minutes after the first viewer opened one, until Egret is restarted: the idle reaper cannot stop the app process.
 
 ## Further reading
 

platform/known-issues.md

@@ -37,7 +37,7 @@ and missing pieces. Entries are **recorded, not fixed**; they feed the product r
 
 ## Findings from the detailed pages
 
-Collected while writing the detailed pages for each area (October 2026), checked against the running demo instance and the product source. KI-154 to KI-213 come from re-verifying every area on the Docker demo stack (`just demo-up`, October 2026), which also closed or updated older rows (marked *Status* or *Docker demo stack*). KI-214 to KI-235 come from a whole-app UI consistency sweep of 78 screens (admin, light theme, 1440×900, same stack), then the dark theme, 768 and 390 px widths, the editors and a non-admin member. Same legend as above. **Open S1 items:** KI-059, KI-060, KI-112, KI-136, KI-159, KI-175, KI-187 (KI-040 is closed).
+Collected while writing the detailed pages for each area (October 2026), checked against the running demo instance and the product source. KI-154 to KI-213 come from re-verifying every area on the Docker demo stack (`just demo-up`, October 2026), which also closed or updated older rows (marked *Status* or *Docker demo stack*). KI-214 to KI-235 come from a whole-app UI consistency sweep of 78 screens (admin, light theme, 1440×900, same stack), then the dark theme, 768 and 390 px widths, the editors and a non-admin member. Same legend as above. **Open S1 items:** KI-059, KI-060, KI-112, KI-136, KI-159, KI-187 (KI-040 and KI-175 are closed).
 
 ### Data API, Alerts and Apps
 
@@ -71,7 +71,7 @@ Collected while writing the detailed pages for each area (October 2026), checked
 | KI-171 | Alerts / Run log | UX | S3 | In a report's run log dialog the **Value** column is empty and too narrow: its heading runs into **Detail** ("ValueDetail") and **Started** wraps. *Steps:* Reports tab → Run log of **Sales performance weekly digest** (screenshot `alerts/run-log-report-error`). |
 | KI-172 | Alerts API | Docs | S3 | For a report, a non-empty `targets` silently replaces `chart_id`/`dashboard_id`: `POST /alerts` with `dashboard_id` = Sales performance and `targets` = [chart Top clerks] delivered a PDF of the chart alone and recorded **Success**. The editor always sends every object (primary first) in `targets`, so only API clients hit this, and the API reference does not say so. *Steps:* `runner.rs` `render_image_report` uses `targets_for` when non-empty. |
 | KI-173 | Alerts / Scheduler | UX | S3 | Items due in the same tick run one after another, so a slow PNG/PDF render delays every other alert in the workspace: twelve items due at 12:10:00 started between 12:10:18 and 12:11:21, all showing **Working** meanwhile; an alert with a dashboard attachment takes about 25 s per run. *Steps:* set twelve items to `*/2 * * * *`, watch `GET /alerts` `last_state`. |
-| KI-175 | Apps | Bug | S1 | On the Docker demo stack published apps stop opening a few minutes after the first view: every later **Open** stays on *Starting the app…* until Egret is restarted. The egret image has no `kill` binary, so `SubprocessPodLauncher::kill_group` (`crates/egret-apps/src/subprocess_pod.rs`) cannot signal the process group; when the idle reaper calls `stop_run`, it waits forever on `child.wait()` while holding the `running_run` mutex (the guard of `self.running_run.lock().await.remove(&key)` lives through the block), and every `ensure_run` blocks behind it. Edit pods use a separate lock and keep working, but `stop_edit` (idle 30 min) likely has the same problem. *Workaround:* restart the egret container. *Fix idea:* install procps or use `killpg`, and do not hold the mutex across `kill_group`. *Steps:* open a published app as a viewer; more than 5 minutes later open another (`Customer lookup`): `POST …/ticket` 200, `GET http://apps.localtest.me:18080/r/<key>/` never answers, the first run's processes are still alive and the log has no "stopped an idle app run pod". Seen twice. |
+| KI-175 | Apps | Bug | S1 | On the Docker demo stack published apps stop opening a few minutes after the first view: every later **Open** stays on *Starting the app…* until Egret is restarted. The egret image has no `kill` binary, so `SubprocessPodLauncher::kill_group` (`crates/egret-apps/src/subprocess_pod.rs`) cannot signal the process group; when the idle reaper calls `stop_run`, it waits forever on `child.wait()` while holding the `running_run` mutex (the guard of `self.running_run.lock().await.remove(&key)` lives through the block), and every `ensure_run` blocks behind it. Edit pods use a separate lock and keep working, but `stop_edit` (idle 30 min) likely has the same problem. *Workaround:* restart the egret container. *Fix idea:* install procps or use `killpg`, and do not hold the mutex across `kill_group`. *Steps:* open a published app as a viewer; more than 5 minutes later open another (`Customer lookup`): `POST …/ticket` 200, `GET http://apps.localtest.me:18080/r/<key>/` never answers, the first run's processes are still alive and the log has no "stopped an idle app run pod". Seen twice. *Status:* fixed in platform #707 (`eae470b6`, October 2026): the launcher signals the group with `killpg` and waits at most 5 s after SIGKILL. Checked on a rebuilt demo image: the idle reaper logged *stopped an idle app run pod* about 5 minutes after the first view, and the next **Open** started a new pod in 3 s. `stop_run` still holds the `running_run` lock while it waits, now for 5 s at most (10 s in the worst case), and `stop_edit` shares the fix. |
 | KI-176 | Apps | Bug | S3 | The **Versions** dialog is stale after a publish (still *Nothing has been published yet.*) until the page is reloaded: `usePublishApp` (`frontend/src/api/apps.ts:119`) invalidates the app and the list but not `getAppsVersionsQueryKey`, while `useRestoreVersion` does. *Steps:* new app → Versions → Ctrl+S → **Publish draft rev 2** → toast *Published version 1* → Versions still empty; reload → `v1`. |
 | KI-177 | Apps | UX | S2 | **Publish draft rev N** pressed right after Ctrl+S answers `409 {"error":"the draft changed since it was read","current_revision":2}` (toast *The draft changed while you were publishing…*), because the header re-reads the draft revision only every 5 s (`useApp(..., {refetchMs})`). *Workaround:* wait until the button shows the new revision, then publish. *Steps:* new app → cell `1 + 1` → Ctrl+S → **Publish draft rev 1** within 0.3 s → 409; about 7 s later **Publish draft rev 2** works. |
 | KI-178 | Apps | Gap | S3 | The Data Apps image ships `plotly` (7.1.0) and `altair` but not `numpy` or `pandas`, so `import plotly.express` fails (*Plotly Express requires numpy to be installed*) and so does anything that calls `.to_pandas()`. Only Altair (`mo.ui.altair_chart`) and `plotly.graph_objects` with lists work. *Steps:* `python3 -c "import plotly.express"` in the egret container; `apps-image/constraints.txt` has no numpy. |