[v10] Fix setState() silent failure causing state/status desynchronization

[acourtiol]

This is the v10 equivalent of #3289 (submitted against main-9).

What this PR does

Adds a fallback in Helper/Order.php::setState() so that when the $possibleStates constraint (from STATE_TRANSITION_MATRIX) doesn't produce a match, the method falls back to a direct lookup in sales_order_status_state for the given status. This prevents the order state from being permanently stuck at its previous value while the status advances.

Why this is needed

Currently, setState() iterates $possibleStates and if no match is found, it logs a notification and returns without changing the state. Meanwhile, the status was already updated by the caller (addStatusHistoryComment calls setStatus() internally). This leaves the order with a mismatched state/status that never gets corrected.

On our production instance, this resulted in 63,805 orders with state=pending_payment + status=complete/closed since 2021. The code is identical in v9.20.13 and v10.10.0.

How it works

After the existing $possibleStates loop fails, the fix does a direct lookup in sales_order_status_state:

$fallbackStatus = $this->orderStatusCollectionFactory->create()
    ->addFieldToFilter('main_table.status', $status)
    ->joinStates()
    ->getFirstItem();

if ($fallbackStatus->getState()) {
    $order->setState($fallbackStatus->getState());
    return $order;
}

The preferred STATE_TRANSITION_MATRIX states are still tried first. The fallback only activates when no preferred match is found.

Related

• Fixes [Bug]: Helper/Order.php: setState() silently fails when status maps to a state not in STATE_TRANSITION_MATRIX, causing permanent state/status desync #3288
• v9 PR: [v9] Fix setState() silent failure causing state/status desynchronization #3289
• Related: Captured orders stuck in pending_payment state #1767, [PW-8506] Wrong Order status when configuration field 'payment_pre_authorized' is set #2097, [Bug]: Mobile Pay orders that getting cancelled are stuck in pending status #3269

[gemini-code-assist]

Code Review

This pull request introduces a fallback mechanism in the setState method to resolve order states directly from the database when preferred state mappings are unavailable, preventing state/status desynchronization. Feedback suggests improving logging consistency by using the getOrderContext method and ensuring deterministic results in the fallback query by ordering by the is_default flag.