Skip to content

App manifest: add explicit autostart flag#350

Open
woltspace-jerpint[bot] wants to merge 1 commit into
mainfrom
uxw/app-autostart
Open

App manifest: add explicit autostart flag#350
woltspace-jerpint[bot] wants to merge 1 commit into
mainfrom
uxw/app-autostart

Conversation

@woltspace-jerpint

Copy link
Copy Markdown
Contributor

Summary

  • Adds autostart: bool (default false) to the woltspace.json schema in container/lib/apps.py.
  • New apps_autostart() function: iterates discover_apps(), filters to autostart=true, calls start_app(name) for each.
  • Wired into FastAPI lifespan after apps_restore().
  • start_app is already idempotent (returns existing state if PID is alive), so apps already revived by apps_restore are a no-op.

Closes #349.

Why

Today, boot-time intent is implicitapps_restore() infers "user wants this on" from the presence of a runtime state file in .space/apps/. That's clever but the source of truth lives in the wrong place. Reading the manifest should tell you whether an app comes up on boot.

Two wolts (Loup, lolo's lab) have been working around this by writing wolf.json script crons to keep their services up (see #347). Wolf is for scheduled wolt sessions, not service supervision — "keep my app on" belongs in the app manifest.

Migration

  • Default autostart: false — no behavior change for existing manifests.
  • Existing users relying on "start once via lodge/CLI, expect restart-restore" continue to work via apps_restore (preserved).
  • Wolts who want declarative boot-up add "autostart": true to their woltspace.json and drop any wolf-cron workarounds.

Test plan

  • 8 new tests in test/test_woltspace_apps.py:
    • Default autostart=False on the schema
    • Manifest field is parsed
    • Empty case (no autostart apps → no-op)
    • autostart: false does nothing
    • autostart: true starts the app
    • Idempotent when already running (no duplicate spawn)
    • Skipped when manifest has no start command
    • Failure is recorded, doesn't stop the loop
  • Full suite: 377 passed, 2 pre-existing failures unrelated (test_telegram_loop, test_wolt_sites)
  • Manual test: rebuild container with autostart: true on an app, confirm it comes up after woltspace stop && woltspace start

Out of scope (follow-ups)

  • Demoting state files from "intent" to pure runtime status
  • PID + create_time hardening to eliminate PID-reuse false positives
  • Lodge UI checkbox to toggle autostart per app

Adds an opt-in `autostart` boolean to the woltspace.json manifest. Apps
flagged autostart=true are launched on container boot via a new
apps_autostart() called in FastAPI lifespan, after apps_restore().

start_app() is already idempotent (returns existing state if the PID is
alive), so apps revived by apps_restore are a no-op here.

Closes #349.
@vercel

vercel Bot commented May 29, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
woltspace Ready Ready Preview, Comment May 29, 2026 12:20pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

App manifest: add explicit autostart flag for boot-time launch

0 participants