)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":38864,"name":"Sridhar Kumar Ettkepalli","display_name":"Sridhar","email":"sridharkumar.ettkepalli@windriver.com","username":"settkepa"},"change_message_id":"1e4a341243a4ed59c2ff3cede8c56aebe596d03e","unresolved":true,"context_lines":[{"line_number":3,"context_line":"AuthorDate: 2026-10-13 09:41:22 -0400"},{"line_number":4,"context_line":"Commit:     asyed1 \u003cahmed.syed@windriver.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2026-10-13 13:40:15 -0400"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Tolerate transient InstanceActionNotFound on instance actions"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"A stop issued during an upgrade was accepted by nova-api but never"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"d8b84102_da3a7a2c","line":6,"updated":"2026-10-13 21:34:25.000000000","message":"Adding a bit more on when this actually bites, since the root cause isn\u0027t obvious from the diff alone.\n\nIt needs a multi-member Galera cell DB where reads and writes can land on different members (connection pointed at a load-balanced/headless endpoint, not pinned to one node), plus enough write load that one member falls a few seconds behind applying writesets. That\u0027s a normal HA setup, not a broken one. In that window nova-api writes the instance_actions row and casts stop_instance, nova-compute calls action_event_start and reads the row back by request_id before driver.power_off, and if that read hits the member that hasn\u0027t applied the write yet it gets InstanceActionNotFound. task_state gets reverted, the VM is left ACTIVE, and there\u0027s no fault or notification - the row shows up a moment later but nova never looks again. We saw apply lag of 7-15s; the miss itself was sub-second.\n\nThe reason I think this belongs in nova and isn\u0027t just \"set wsrep_sync_wait\" is that nova already retries this same class of transient miss right next door - instance_update has _retry_instance_update and action_event_finish is wrapped in wrap_db_retry. action_event_start was the odd one out. So this isn\u0027t a new assumption, it\u0027s the same pattern applied to the one function that was missing it, and keeping the wrap outside pick_context_manager_writer so each retry actually gets a fresh read. sync_wait would work too but it slows every read and only helps if the operator turns it on.\n\nAnd it stays honest about genuinely missing actions - it warns on each miss so a late success is still visible in the logs, and if the row never appears it still raises InstanceActionNotFound after the retries. Nothing changes on the happy path.","commit_id":"f9c93fbb449093ada2d9668301075ec61fc42f23"},{"author":{"_account_id":38864,"name":"Sridhar Kumar Ettkepalli","display_name":"Sridhar","email":"sridharkumar.ettkepalli@windriver.com","username":"settkepa"},"change_message_id":"2e582a131bc93d8bbe37aed7df99b564f0909b49","unresolved":true,"context_lines":[{"line_number":3,"context_line":"AuthorDate: 2026-10-13 09:41:22 -0400"},{"line_number":4,"context_line":"Commit:     asyed1 \u003cahmed.syed@windriver.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2026-10-13 13:40:15 -0400"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Tolerate transient InstanceActionNotFound on instance actions"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"A stop issued during an upgrade was accepted by nova-api but never"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"bedce586_5800d7db","line":6,"updated":"2026-10-13 21:46:05.000000000","message":"One thing worth adding: a release note. There\u0027s an operator-visible effect here - a stop that used to silently fail now completes, and there\u0027s a new warning logged during the transient - so I think this warrants a short fixes: reno rather than going in silently. Something like:\n\nfixes:\n  - |\n    Fixed an instance action such as ``stop`` failing with\n    ``InstanceActionNotFound`` on a replicated database. The parent\n    ``instance_actions`` row is written by nova-api and read back by\n    nova-compute via ``action_event_start``; on a clustered database\n    such as a Galera cluster, where a write is certified cluster-wide\n    but applied asynchronously, that read can land on a member that has\n    not yet applied the write, so a row that exists is briefly not\n    visible and the action is abandoned. The lookup now retries,\n    consistent with the existing retries on ``instance_update`` and\n    ``action_event_finish``, and still raises if the row never becomes\n    visible.","commit_id":"f9c93fbb449093ada2d9668301075ec61fc42f23"}]}