Conversation
fiftin
commented
Feb 18, 2026
- feat(app): support app versions
- feat(ui): app version
- feat(apps): version reorder
- feat(apps): add app version to template
- fix(apps): do not use content for app id
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 402c8c1c59
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| func (d *BoltDb) UpdateAppVersion(version db.AppVersion) error { | ||
| return d.updateObject(0, db.AppVersionProps, version) | ||
| } |
There was a problem hiding this comment.
Scope Bolt app-version mutations to the requested app
In the Bolt implementation, app-version mutations are keyed only by id: UpdateAppVersion calls updateObject directly and DeleteAppVersion deletes by versionID without verifying appID, so a request to /apps/{app_id}/versions/{version_id} can modify or remove a version that belongs to a different app if that ID is supplied. The SQL implementation guards this with where app_id=? and id=?, so Bolt currently allows cross-app data corruption.
Useful? React with 👍 / 👎.
| func (d *BoltDb) DeleteApp(appID string) error { | ||
| return d.db.Update(func(tx *bbolt.Tx) error { | ||
| return d.deleteObject(0, db.AppProps, strObjectID(appID), tx) | ||
| }) |
There was a problem hiding this comment.
Delete Bolt app versions when deleting an app
DeleteApp in Bolt removes only the app object and never removes related app__version records. This leaves orphaned version rows behind, and recreating the same app ID later can resurrect stale versions (old path/args) unexpectedly. SQL avoids this with foreign-key cascade, so Bolt behavior is inconsistent and can lead to persistent stale configuration.
Useful? React with 👍 / 👎.
| <div class="mb-4"> | ||
| <v-autocomplete | ||
| v-if="appVersions && appVersions.length > 0" | ||
| v-model="item.app_version_id" |
There was a problem hiding this comment.
Make template app_version_id affect task runtime
This adds a template-level version selector (item.app_version_id), but task launch paths still resolve executables from util.Config.Apps[string(t.App)] (for example in db_lib/ShellApp.go) and there is no read path that applies Template.AppVersionID, so selecting a non-default version does not change what binary/args are executed. In practice, users can save a version in the UI and still run the wrong app version in production.
Useful? React with 👍 / 👎.