Skip to content
MantleMantle docs

Release 0.233

0.233.2: app export, import and duplicate; the app error log (apps first-class, Phase 3)

  • .mantleapp export and import. GET /api/apps/:id/export downloads a zip of the code and a copy of the data (?data=0 without). POST /api/apps/import-package (the file as the raw body) makes a new app from one: the package, schema and database (SQLite quick_check, then a clean copy in the SQL child) are checked before anything is made; the code is built here and published when it was published; unknown tools are left out and reported. docs/app-authoring-guide.md, “Export, import and duplicate”.
  • Duplicate. app_duplicate / POST /api/apps/:id/duplicate copies an app with its builds (live at once), draft, tools, schema and data (with_data: false for code only). Admin-only, unshared, no history but a “copied from” version, no table exports.
  • App error log (G4). Every broker (owner, member, client, share) logs the errors it answers a running app with: kind error in app_access_log, with the message, the SQL or the tool slug, who ran it and the status. Capped at 30 rows per app per minute; busy waits are not logged; a server fault keeps the generic text. Read with app_errors (owner only, group apps) or GET /api/apps/:id/access-log?kind=error (kind and limit are new). An access-log write that throws before it is sent no longer reaches the caller.
  • App table exports survive a restart (D8). The first app write of a burst stamps the app’s exports dirty_since (migration 0221, 0221_app_table_exports_dirty); the sync that reads the rows clears it. The web process resumes the dirty ones at boot. The maintenance task app-export-catch-up (pnpm -C server/web app-export:catch-up, dry run unless --apply) syncs any dirty for 20 minutes; by hand only, since a changed table is re-indexed (not on the nightly cron).

0.233.1: recently deleted apps, app_update, an import that checks first (apps first-class, Phase 3)

  • Recently deleted. Deleting an app keeps a pre_delete snapshot (code, name, look and data) and its history for 30 days; it comes back with the same id (app_undelete, POST /api/apps/deleted/:id/restore), admin-only and unshared. app_deleted_list / GET /api/apps/deleted list them; DELETE /api/apps/deleted/:id purges one now; the nightly app-trash-purge sweep (pnpm -C server/web app-trash:purge) after 30 days. A delete whose snapshot cannot be taken does not happen.
  • Migration 0220 (0220_node_snapshots_outlive_node): drops the node_snapshots foreign key so the history outlives the app.
  • app_update: rename an app, change its description, icon, colour or tags. PATCH /api/apps/:id takes description.
  • Import checks first. POST /api/apps/import validates the tool slugs and tries the schema before it writes anything (a bad one used to leave a half-made app), follows the create route’s field rules, and snapshots an existing app before it overwrites it.
  • One build step (buildAndStageApp in @mantle/tools) behind app_build, Preview, Commit, import and apps:push.

0.233.0: app history, versions and snapshots (apps first-class, Phase 2)

An app’s code AND its data can now be put back (docs/app-authoring-guide.md, “History: versions and snapshots”).

  • Versions. Every publish records the code that went live, with an optional note (app_publish takes note).
  • Snapshots. The code and a copy of the app’s database (app_snapshot_create, or the History tab). One is taken automatically before every restore and before app_db_schema_set changes the schema of an app with data. The newest 20 automatic ones are kept per app; the owner’s own count against APP_SNAPSHOT_MAX_MB (default 2048).
  • Restore in three modes (app_snapshot_restore, confirm-gated, or POST /api/apps/:id/snapshots/:sid/restore): code into the draft, data back as the live database, full both live. A data restore puts a marker beside the file: every broker and the SQL child answer busy (429) for the few seconds the swap takes.
  • Routes: GET/POST /api/apps/:id/snapshots, GET/PATCH/DELETE …/snapshots/:sid, …/restore, …/download (the .sqlite copy).
  • Tools: app_snapshot_create, app_snapshot_list (group apps); app_snapshot_restore, app_snapshot_delete (group app-admin, both confirm-gated).
  • Contract: @crossworks/client-types gains AppSnapshot and AppRestoreMode. Additive.
  • The backup copies each app’s snapshots with its database; deleting an app removes them.
  • Migration 0219 (0219_node_snapshots): the node_snapshots table (one numbered line per item, apps now, tables later), apps.restored_from_seq, and v1 for every published app (pure SQL).