Hi team,
I found a consistently reproducible versioning issue with an existing app_bundled Executa.
anna-app executa publish reports success, generates a new content hash, and returns idempotent_hit: false, but no new ExecutaVersion is created. As a result, an app release can only freeze the previous Executa version.
Issue summary
The affected Executa is:
| Field | Value |
|---|---|
| CLI | @anna-ai/cli 0.1.38 |
| Host | anna.partners |
| Executa | tool-gamentic-engine-7h8aweky |
| executa_id | 1025 |
| Visibility | app_bundled |
| is_published | FALSE |
| Previous registered version | 0.2.13 |
| Previous latest_version_id | 349 |
The associated app is gamentic-anna (app_id: 19). Its manifest references the Executa through:
{
"required_executas": [
{
"tool_id": "tool-gamentic-engine-7h8aweky",
"min_version": "0.2.15",
"version": "0.2.15"
}
]
}
However, the Executa registry remains on 0.2.13, even after publishing 0.2.14 and 0.2.15.
Reproduction
Preconditions
Start with an existing Executa that has:
visibility: app_bundled
is_published: false
latest registered version: 0.2.13
latest_version_id: 349
The 0.2.15 package has already been published to PyPI, and executa.json contains version 0.2.15.
Run the following commands from the Executa’s backend directory:
cd ~/anna-dev/gamentic-anna/backend
anna-app executa status engine --json
anna-app executa publish --json
anna-app executa status engine --json
Before publishing, the status reports:
{
"version_count": 13,
"latest_version": {
"version": "0.2.13",
"id": 349
}
}
The publish command returns successfully:
{
"executa_id": 1025,
"version": "0.2.15",
"content_hash": "11eea73a4555f8d71d07c6fdf2e98c3f492f99a86ff7aa63a60badec203ab8b4",
"idempotent_hit": false,
"first_publish": false,
"visibility": "app_bundled",
"latest_version_id": 349
}
The previous 0.2.13 content hash was:
0f53a1c7...
Therefore, this is a new publish payload rather than an idempotent retry.
After the publish command succeeds, running the status command again still reports:
{
"version_count": 13,
"latest_version": {
"version": "0.2.13",
"id": 349
}
}
The same behavior previously occurred with version 0.2.14.
Actual result
The publish operation:
- Returns successfully;
- Returns the requested version,
0.2.15; - Produces a new
content_hash; - Returns
idempotent_hit: false; - Does not increment
version_count; - Does not create a new
ExecutaVersion; - Continues returning the old
latest_version_id: 349.
There is no CLI error or warning indicating that version creation was skipped.
Expected result
If executa publish succeeds for an existing bundled Executa, I would expect it to create a new ExecutaVersion.
For this reproduction, the expected status would be equivalent to:
{
"version_count": 14,
"latest_version": {
"version": "0.2.15",
"id": "<new version id>"
}
}
The publish response should also return the newly created version ID instead of 349.
If app_bundled Executas are not supposed to be versioned through this command while is_published is false, the command should return an actionable error rather than reporting a successful non-idempotent publish.
Initial diagnosis
The response suggests that the CLI and backend successfully process the new manifest or artifact:
- The returned version changes to
0.2.15; - The content hash changes;
idempotent_hitisfalse.
The failure therefore appears to occur after content processing but before, or while, registering the corresponding ExecutaVersion.
My current hypothesis is that version creation may be gated by one of these state fields:
visibility = app_bundled
is_published = false
A possible backend path is:
accept new publish payload
→ calculate/store new content hash
→ skip ExecutaVersion creation because the Executa is not publicly published
→ return success with the previous latest_version_id
This would explain why the response contains the new version and hash while latest_version_id and version_count remain unchanged.
Another possibility is that bundled Executas require a separate registration or state-transition step that is not performed by anna-app executa publish.
I also checked the app publication path. The app references the Executa by tool_id through required_executas, but:
anna-app apps push --dry-run
only stages the app UI bundle. It does not register a new Executa version. Therefore, I could not identify another command in the current workflow that would create the missing ExecutaVersion.
Impact
This blocks app releases that depend on a newer bundled Executa version.
Although the app requests version 0.2.15, the platform can only resolve or freeze the last registered version, 0.2.13. The package and app manifest may therefore move forward while the platform’s Executa registry silently remains behind.
The successful publish response is also misleading for CI or release automation because it cannot be used as evidence that a new version was registered.
Requested confirmation or action
- Please confirm whether
anna-app executa publishis expected to create anExecutaVersionfor anapp_bundledExecuta withis_published: false. - If this is expected behavior, please check whether the backend is incorrectly skipping version creation while still returning a successful, non-idempotent publish response. An officially supported workaround would also be helpful.
If this state is intentional, could you also clarify the required command or state transition for registering a new bundled Executa version?
Thank you.
What was actually happening
Fixed in 
For pip/uv/npm-style distributions, the declared version is now part of the content fingerprint ([package@version] is the code identity). Bumping 
If a publish dedupes against an existing version but you requested a different version number, you now get an explicit 409 explaining the conflict — never a fake success.
Your questions
Happy shipping! 
