serve.zone/onebox
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 82 Wiki Activity

82 Releases 305 Tags

RSS Feed
  • v32.5.6 2bd6550fa6
    Compare

    Onebox v32.5.6
    Release / build-and-release (push) Successful in 20m59s
    Details
    Stable

    jkunz released this 2026-09-24 10:59:49 +00:00 | 148 commits to main since this release

    2026-09-24 - 32.5.6

    Fixes

    • Let a new service that maps the Cloudly WorkloadInit approval file receive its first approval. The approval owner admits an approval only through its verified stage, and the stage needs an existing service with the mapping, but no deployment could create one: the secret store refused the approval among the deployment's secrets, and without it the runtime refused the mapping, so an App Store install of Cloudly on a new host, whose template requires the approval, always failed and the documented recovery of Cloudly on another host was impossible. A deployment that maps the file now takes the offered approval out of the secrets it writes, creates the service without it and hands it to the owner's stage, which verifies it, requires an active approval, records it as the service's first accepted authority and creates the runtime with its root-only mapping, and then starts the service. A deployment that maps the file without offering an approval is refused by name before a service exists, and one whose approval the stage refuses is rolled back. An import or clone of a backup that carries an approval stays refused.
    • Remove a service's WorkloadInit approval state when the service is deleted, and the state earlier deletions left behind. OneboxDatabase.deleteService removed the service record and its encrypted secrets but left the approval owner record and every history event, and a new service receives the highest stored id plus one, so a service created after the highest-numbered one was deleted inherited its approval history and generation floor, and the owner then expected an approval the new service's secrets did not hold: an in-place restore of that service was refused, and with the approval mapping it could never stage an approval. Deleting a service now ends with one transaction, WorkloadInitApprovalsStore.deleteService, that removes the service record, its encrypted secrets, its approval owner record and its whole history together, under the same service mutation lock, and refuses while an approval operation is pending, so a delete that fails at any point leaves the service with its approval, owner record and generation floor or removes all of them. The data migration workloadinit-orphaned-approvals (data version 0.20.0 → 0.21.0) removes, through WorkloadInitApprovalsStore.deleteOrphanedOwnership, the owner record, pending operation and history that no service owns: those of every service that no longer exists, and those under the id of every existing service that carries no approval file mapping, which inherited them when it reused a deleted service's id. Every approval Onebox recorded belonged to a service carrying the mapping, through the owner's stage and the ownership import of released custody alike, and every writer of a service's secret files refuses to remove it, so approval state under a service without the mapping was inherited. Each service id's state goes in one transaction that re-reads the service and refuses by name when it carries the mapping or is held by an approval operation, so a mapped service's approval state is never touched and a second run finds nothing. A pending operation is removed with the rest, because its hold was a field of the deleted service record and nothing can resume or deliver it; start-up used to refuse to start on a pending operation whose service was gone with Pending WorkloadInit approval service is missing and now removes it the same way. This is the first data migration since 32.0.0 and it has no reverse step: once this release has moved a database to 0.21.0, Onebox 32.5.5 and older refuse to start against it, so going back to an older release needs the database as it was before the upgrade. Back up before upgrading.

    Maintenance

    • Move @serve.zone/appstore from 32.1.1 to 32.2.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Its cloudly template 1.2.1 moves Cloudly from 32.9.0 to 32.9.1 (code.foss.global/serve.zone/cloudly@sha256:f0da8c0ef826d2e044aa49ec1b59533f7be16c372357dbf818fe488ccdc5b0c9), a fixes-only patch with no data migration step that keeps the 1.2.0 runtime contract, so the template marks the upgrade from 1.2.0 as needing no manual review, data migration or backup; it requires Onebox 32.4.0, and an installation on 1.1.10 or earlier still runs the 1.2.0 startup migration to 0.20.0 on this image. Onebox reads the App Store from the catalog this package bundles, so the App Store upgrade of central's Cloudly from template 1.2.0 to 1.2.1 needs a Onebox release that carries this move. The App Store upgrade test now prepares the 1.2.0 to 1.2.1 upgrade of an install running the 1.2.0 image, as central does. App Store 32.2.0 still pins @serve.zone/interfaces 32.3.0, so its own copy is unchanged and no other package moves.
    • Name the installed @serve.zone/interfaces 32.15.0 and @serve.zone/corestore 32.4.1 in the readme's platform contracts. 32.5.4 moved both, and the readme still named 32.3.0 and 32.0.1.
    • Raise the release tooling to @git.zone/tswatch ^4.0.0, from ^3.3.5; @git.zone/tsbuild ^5.0.0, @git.zone/tsbundle ^2.14.0, @git.zone/tsdeno ^1.8.0, @git.zone/tsrun ^3.0.0 and @git.zone/tstest 6.2.0 are already current. The breaking changes of tswatch 4.0.0 do not reach Onebox's tswatch configuration in .smartconfig.json, which has only bundles and watchers, so no migration applies: its dev server now serves the service worker of @api.global/typedserver 13, but that configuration starts no dev server; bundles[].triggerReload is removed, and Onebox's bundle does not set it; and every command a watcher runs now gets TSWATCH=true, which only typedserver 13 and later reads, while the backend that pnpm run watch starts runs typedserver 11.2.1. The binary's deno.lock does not reference tswatch and is unchanged. In the development tooling only, the pnpm lock replaces tswatch 3's @api.global/typedserver 8.12.0 with 13.0.2 and brings @push.rocks/smartserve 7.2.0 and @push.rocks/smartwatch 6.5.0 for it. @types/node stays 26.6.1 and pnpm stays 12.4.2, because @types/node 26.6.2 and pnpm 12.5.0 to 12.6.0 are inside the seven-day release-age window.
    Downloads