Make Odoo stable bootstrap a durable operation

[cbusillo]

Objective

Move Odoo stable bootstrap from a long-running synchronous service request into a durable Launchplane operation record that can be started, observed, retried, and audited without holding one HTTP request open through Dokploy schedules, post-deploy, and public verification.

Finish Line

The GitHub Odoo Stable Bootstrap workflow submits a bootstrap operation, receives an operation id, polls or watches operation status, and fails or passes from persisted operation evidence rather than from a single synchronous 202 response.

Current Status

State: Evidence-preservation slice merged in PR #561. Failed Odoo Stable Bootstrap workflow runs now still upload odoo-stable-bootstrap.json when the response file exists, so operators keep the service result artifact even when the run fails. Full durable operation design remains open.
Next action: Design and implement the operation record/create-read-poll flow for the full async implementation.
Blocked by: Executor placement decision for the full async operation model.
Last verified: 2026-05-10; PR #561 and post-merge main CI, Security, and CodeQL checks passed. Open code scanning alerts: 0. Open Dependabot alerts: 0.

Scope

• Add an Odoo bootstrap operation/request record with requested policy, target proof snapshot, status, phase, result, timestamps, and failure details.
• Add service routes to create/read an operation, with idempotency tied to operation creation rather than replaying a full bootstrap response.
• Refactor the GitHub workflow to submit, poll, and upload operation evidence on success and failure.
• Ensure failures keep enough evidence for operator diagnosis even when the workflow fails.
• Keep execution single-flight per product/context/instance.
• Preserve existing service authz and driver descriptor boundaries.

Acceptance Criteria

• The submit route returns quickly with an operation id and does not block on Dokploy schedule completion.
• A poll/read route exposes phase-specific statuses for policy proof, target proof, bootstrap run, post-deploy, health, canonical, logo, and runtime identity verification.
• GitHub Actions uploads the operation/result artifact even when the operation fails.
• Re-running a successful workflow cannot silently execute another destructive bootstrap unless a new operation is explicitly requested and accepted.
• Concurrent operations for the same lane are rejected or queued deterministically.
• Tests cover operation creation, idempotency, polling, failure artifact behavior, single-flight refusal, and status transitions.

Relationships

• Blocks Add service-backed Odoo stable bootstrap workflow #542 because the current bootstrap workflow should not remain synchronous for real tenant rebuilds.
• Blocks Add safe Odoo stable target replacement workflow #520 because stable target replacement/recreate flows need durable operation state and polling.
• Related to Replace hard-coded Odoo bootstrap allowlist with lane policy #555 because policy/target proof should be captured as early operation phases.

Validation

• Unit tests for operation record serialization and state transitions.
• Service tests for create/read/idempotency/single-flight behavior.
• Workflow test or shellcheck-style validation that failed operations still upload result JSON.
• Live CM testing no-op or dry-run operation before another destructive bootstrap.

Decisions

• A destructive bootstrap is an operation, not a normal synchronous API action.
• The first implementation can still be GitHub-workflow-driven; it just should not depend on one long HTTP response.

Open Questions

• Should the operation executor run in the Launchplane service process, a scheduled GitHub workflow loop, or a dedicated worker?
• What is the retention policy for operation records and artifacts?
• Should operation creation require a separate approval record for prod-capable lanes?

[cbusillo]

Status update 2026-05-10:

Merged another bootstrap durability slice in #565. Odoo stable bootstrap now catches post-deploy ClickException failures and writes structured bootstrap/post-deploy evidence instead of letting the service route fail with an unhandled exception. This preserves the important distinction that the destructive bootstrap command ran (bootstrap_run_status=pass) while readiness/post-deploy failed.

Verified on #565 and post-merge main:

• CI: success
• Security: success
• CodeQL: success
• code scanning open alerts: 0
• Dependabot open alerts: 0

Still open for this issue: durable async create/read/poll operation records and timeout/continuation handling for long-running Dokploy schedules.