feat: Implement cross-type app conversion and enhance version management#2
Conversation
mrMigles
commented
Jul 20, 2026
mrMigles
commented
- Added support for switching app types (script ↔ project) with user confirmation.
- Introduced pending state management for type conversions and source changes.
- Enhanced versioning to include type and app-specific metadata.
- Updated README to reflect new type conversion features and rollback capabilities.
- Added comprehensive tests for type conversion scenarios and version management.
- Added support for switching app types (script ↔ project) with user confirmation. - Introduced pending state management for type conversions and source changes. - Enhanced versioning to include type and app-specific metadata. - Updated README to reflect new type conversion features and rollback capabilities. - Added comprehensive tests for type conversion scenarios and version management.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5659640ece
ℹ️ 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".
| tmp_conv.write_bytes(file_bytes) | ||
| try: | ||
| await query.edit_message_text(f"⚙️ Converting {script_id} to script ...") | ||
| full_id = script_mgr.upsert_script_from_file(original_name, tmp_conv) |
There was a problem hiding this comment.
When Change Source is used to replace an existing app with a .py file whose filename differs from the target ID, this call derives full_id from original_name instead of using script_id. The new script is therefore created under the uploaded filename, while the original app remains unchanged; this contradicts the preceding forced-target routing and leaves the requested conversion unperformed.
Useful? React with 👍 / 👎.
| app_id = info["app_id"] | ||
| repo_dir = GITREPOS_DIR / app_id | ||
| repo_url = f"https://github.com/{info['owner']}/{info['repo']}.git" |
There was a problem hiding this comment.
For a GitHub-to-GitHub Change Source, force_target_id makes the new repository reuse the old app's GITREPOS_DIR/<id> clone. Since git_clone_or_pull fetches the existing clone's origin, it stages the old repository rather than the newly supplied URL, then writes metadata for the new repo; subsequent Sync operations continue fetching that old origin. Replacing a GitHub source with a different repository therefore silently runs the wrong code.
Useful? React with 👍 / 👎.
| py_files = discover_python_files(dest_root) | ||
| entry, _ = pick_entry_from_candidates(py_files) |
There was a problem hiding this comment.
For an app that had multiple Python files and whose owner selected an entry through entrypick, rollback now recomputes the entry from the restored tree. pick_entry_from_candidates returns None for that ambiguous layout, and no pending choice is registered, so start_script subsequently rejects the restored app with “Entry point not set.” The old rollback preserved the configured entry; the version metadata or rollback flow needs to retain it.
Useful? React with 👍 / 👎.
1 participant
