4 Commits

Include renames

Author	SHA1	Message	Date
ChuckandClaude Opus 5	c9c258ac49	fix(starlark): the six review findings that were still real ... CodeRabbit raised eight on this PR. Two were already fixed by later commits (the F541 f-string prefixes, and the twenty-four CodeQL path-injection alerts, now zero open and the last two dismissed as false positives). These are the rest, each verified against the code as it stands rather than as it was reviewed. Manifest writes shared one temp file. `with_suffix('.tmp')` is a fixed path, and five routes write the manifest while Flask serves requests concurrently -- two writers opened `manifest.tmp`, interleaved their json.dump output and both renamed. The rename is atomic; the content it published was the mixture, which the next read cannot parse. mkstemp in the destination directory gives each writer its own file. A failed import stayed cached. Both dynamic importers insert into sys.modules before exec_module, which they must, but left the half-initialised module behind on failure -- every later call then took the cache branch and raised AttributeError on the missing class instead of retrying, so one transient failure disabled the repository or the renderer for the life of the process. The keys stay unprefixed: the plugin's own manager.py does `from pixlet_renderer import PixletRenderer`, and sharing that key is what keeps one module object. Config was applied before it was saved. A false from save_config() answers 500, but the loaded app kept the new values, so GET config reported settings that were never written and the plugin rendered with them until a restart silently put the old ones back. Snapshot and restore on the failure branch, and do not re-render. The toggle reported success it had not earned. `_update_manifest_safe` returns False on failure and the result was dropped, and the in-memory flag was flipped first -- so a failed write left a toggle that reverted itself on the next restart. Persist first, then update memory. The toggle also could not find what the list had shown. `_starlark_virtual_plugins` publishes the raw manifest key, while the toggle re-slugified it through `_validate_and_sanitize_app_id` (lowercase, every character outside [a-z0-9_] rewritten): an app stored as `My-App` was offered as `starlark:My-App` and looked up as `my_app`, so toggling an app the page had just drawn answered 404. Check for traversal with `_validate_starlark_app_path` and keep the key. `star_file` was stored absolute. Readers join it to the app's own directory and default to a bare `<app_id>.star`, so the key had two meanings -- and `Path.__truediv__` discards the left side when the right is absolute, pinning the manifest to whatever PROJECT_ROOT installed it. Store the filename. Two store tests reached GitHub. browse and categories call list_all_apps_cached(), which fetches the app index on a cold cache -- slow, network-dependent, rate-limitable, and since both only assert "not a 404" a rate-limited 500 passed and hid it. The file now runs in 1.5s rather than 17.5s. 13 new tests, all six findings covered. Whole suite: no new failures against this branch, 3892 passed against 3879. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 16:12:18 -04:00
ChuckBuildsandClaude Opus 5	2a92f1ab3b	fix(starlark): show installed apps with the other plugins, and let them toggle ... An app installed from the store appeared nowhere and could not be enabled or disabled. Same cause as the 404s: #253 surfaced installed apps in /plugins/installed as `starlark:<app_id>` entries and routed `starlark:` toggles to the Starlark manifest, and #330 removed both along with the routes. Without the first, the app store installs successfully into a list nothing renders. Without the second, toggling one falls through to the plugin_manager lookup and answers "Plugin not found" -- a Starlark app is an entry in starlark-apps' own manifest, not a plugin in that sense. Restored as two named helpers rather than the original inline blocks: _starlark_virtual_plugins() reads the loaded plugin when there is one and the on-disk manifest otherwise, so the list is right before starlark-apps loads _toggle_starlark_app() updates through the plugin's own _update_manifest_safe when loaded, or the manifest directly when not Two changes on the original. The toggle now runs app_id through _validate_and_sanitize_app_id first -- it reaches a filesystem manifest and had no validation where the other Starlark routes all have it. And _starlark_virtual_plugins swallows its own failures: the entries are appended to the real plugin list, and a broken Starlark manifest should cost the Starlark rows, not empty the plugins page. 6 new tests covering listing, the fields the UI keys on, toggle persistence, the unknown-app 404, traversal rejection, and that a Starlark failure leaves the rest of the list intact. Full core suite: 3979 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014RRtqXDCnvnY6EQwhT5CV9	2026-09-07 14:31:40 -04:00
ChuckBuildsandClaude Opus 5	2538690435	fix(starlark): restore the remaining eleven routes, so the app store works ... The Pixlet button was the reported symptom; the app store is dead the same way. #330 dropped all thirteen Starlark routes, and browse, categories and install are what the store page is built on -- each answering the generic 404, which from the UI is indistinguishable from an empty store. Restores the other eleven from 1c4d5c52^: apps list and detail, delete, per-app config get/put, toggle, render, manual .star upload, and the Tronbyte repository browse/categories/install. Their dependency closure came with them (8 helpers, resolved by walking the handlers' references rather than by eye), plus the Tuple and Type imports the old file had. Two changes rather than a straight revert. The restored handlers used `request.get_json()` where the file has since standardised on `silent=True`: without it Werkzeug raises on a bodyless POST before the handler's own `if not data` guard runs, so the caller gets a framework error instead of the declared 400. test_api_v3_optional_body.py already checks for exactly that and caught all three. test_every_endpoint_the_frontend_calls_is_registered reads the URLs out of plugins_manager.js and matches each through the URL map, so a rewrite of this file cannot quietly drop the set again -- one assertion over the frontend's own list is what would have caught #330. 26 tests, 17 of which fail against main. Full core suite: 3973 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014RRtqXDCnvnY6EQwhT5CV9	2026-09-07 14:14:23 -04:00
ChuckBuildsandClaude Opus 5	76c5e367ef	fix(starlark): restore the Pixlet install and status routes ... "Pixlet install failed: Resource not found" is Flask's 404 handler. The install button posts to /api/v3/starlark/install-pixlet, that route does not exist, and app.py's generic 404 answers with {"status": "error", "message": "Resource not found"} which the button prints verbatim -- naming neither the resource nor the cause. The routes were added by #253 and removed by #330, which rewrote api_v3.py (3272 lines changed) and dropped all thirteen Starlark routes with it. Nothing else moved: the frontend still calls them and plugin-repos/starlark-apps still implements the work behind them, so every Starlark call in the UI has been landing on the 404 handler since. Restores the two the Pixlet flow needs -- install-pixlet, and the status call the button reloads afterwards -- verbatim from 1c4d5c52^, plus the three helpers they use (_get_starlark_plugin, _find_pixlet_binary, _read_starlark_manifest) and _STARLARK_APPS_DIR. The installer itself is fine; I checked rather than assumed. Against the live release, the naming the script builds matches what tronbyt/pixlet publishes, and the URL resolves: latest tag v0.53.1 asset published pixlet_v0.53.1_linux-arm64.tar.gz script would request pixlet_v0.53.1_linux-arm64.tar.gz HEAD 200 So the missing route was the whole fault. Deliberately scoped to the reported bug. The other eleven routes are still missing -- apps CRUD, config, toggle, render, repository browse and install, repository categories -- and the rest of the Starlark page is still dead. #463 covers those alongside behavioural changes; this stands alone so the install can be fixed without them. test_starlark_pixlet_routes.py asserts both routes are registered and answer in the shape the JS reads, including the not-yet-loaded-plugin case a first-time user is in when they press Install. 8 of its 9 tests fail against main. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014RRtqXDCnvnY6EQwhT5CV9	2026-09-07 13:47:14 -04:00