fix(service-bot): re-publish after offline recreates the destroyed online bot#438
Draft
totalfrank wants to merge 1 commit into
Draft
fix(service-bot): re-publish after offline recreates the destroyed online bot#438totalfrank wants to merge 1 commit into
totalfrank wants to merge 1 commit into
Conversation
…line bot Offlining a SUCCESS service-bot publish tears down its online bot via a BaaS STOP, which for a TeClaw device physically destroys the underlying bot and leaves baas_bot.status = STOPPED (not RELEASED). The re-publish's online stage then took the UPGRADE (UPDATE) path against the destroyed bot and failed permanently with DEVICE_NOT_FOUND. - _should_upgrade_online: treat every gone/not-live baas status (RELEASED, STOPPED, STOPPING, FAILED), not just RELEASED, as first-release so the re-publish issues a fresh CREATE. - operation_runner / bot_build_service.upgrade: classify DEVICE_NOT_FOUND alongside BOT_NOT_FOUND as "target bot gone" so an UPDATE that still hits a destroyed device self-heals into a first release instead of failing the publish. Adds regression tests for the offline->re-publish cycle and both gone-bot error codes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #435.
Offlining a SUCCESS service-bot publish tears down its online bot via a BaaS STOP, which for a TeClaw device physically destroys the underlying bot and leaves
baas_bot.status = STOPPED(notRELEASED). The subsequent re-publish's online stage then took the UPGRADE (UPDATE) path against the already-destroyed bot and failed permanently with[DEVICE_NOT_FOUND] bot not found.The root of the hole: the lifecycle that destroys the bot (offline → STOP →
STOPPED) and the guard that detects a destroyed bot (_should_upgrade_online, which only treatedRELEASEDas "gone") disagreed on the terminal status, so aSTOPPEDprevious bot slipped through as a valid UPGRADE target.Changes
Primary fix —
_should_upgrade_online(upgrade_resolution_mixin.py)Treat every gone/not-live BaaS bot status —
RELEASED,STOPPED,STOPPING,FAILED— as first-release, not justRELEASED. The re-publish now issues a fresh CREATE instead of an UPDATE against the destroyed bot.Defense-in-depth —
DEVICE_NOT_FOUNDclassificationEven if an UPDATE is somehow issued against a destroyed device, the "target bot gone → recreate" self-heal now fires:
operation_runner.py: the deploy atom classifies bothBOT_NOT_FOUNDandDEVICE_NOT_FOUND(new sharedBOT_GONE_ERROR_CODES) asTargetBotGoneError, so the caller falls back to a first release.bot_build_service.upgrade: surfacesDEVICE_NOT_FOUNDas a structured{success: False, error_code: ...}result (likeBOT_NOT_FOUND) instead of raising, so it reaches the classifier rather than failing the publish outright.The two error-code constants are kept in sync by hand (documented in comments); the lower-level
bot_build_servicedeliberately does not import from the publish-flow orchestration package to keep module load order acyclic.Tests
test_should_upgrade_online_forces_first_release_when_prev_bot_gone— parametrized overRELEASED/STOPPED/STOPPING/FAILED.test_execute_release_phase_first_release_when_offlined_online_bot_stopped— the full offline→re-publish cycle at the service layer: previous publishRELEASED+ online botSTOPPEDresolves to first release, not upgrade.test_atom_device_not_found_abandons_with_reason_and_raises— the deploy atom classifiesDEVICE_NOT_FOUND.test_upgrade_teclaw_gone_bot_returns_structured_failure— parametrized over both gone-bot codes on the teclaw upgrade path.All 671 tests under
tests/community/core/service_bot/pass, plus the e2e publish-boundary suite.🤖 Generated with Claude Code
Generated by Claude Code