Odoo Changelog — 2026-04-22

Wednesday, April 22, 2026

2 changes · 19.0

Improvements(2)

Enhancements to existing features

[IMP] core: handle cancelling in `_wait_ready`

Core19.0core

This improvement makes Odoo's internal test runner report the real cause when a websocket connection closes during a readiness check, instead of showing a misleading cancellation error. It should help teams diagnose failed automated runs faster without changing business functionality.

Original PR description

This case induces confusion in the ranks: when the WS connection fails, the result of the run is set to failure then every outstanding response is cancelled.

For `_wait_ready` specifically, because it's a blocking wait on a request it yield a confusing result as the run fails with `CancelledError` and the actual cause (the WS was closed) is lost.

One option would be to `set_exception` on the waiting responses, but I feel like this could create other confusing knock-on effects e.g. more evented waits which currently get ignored might start raising exceptions (although that seems unlikely as callbacks apparently do get called on cancel), and since issues with cancelling only seem to appear in `_wait_ready` that seems like overkill.

Instead have `_wait_ready` handle cancellation by first checking if the result is in error, and using that to raise the underlying error, otherwise retry (and ultimately timeout, probably). And while at it, before signaling a timeout check if the run is in failure and raise that immediately, just in case.

https://runbot.odoo.com/odoo/error/233738

Forward-Port-Of: odoo/odoo#260324

#testing#diagnostics#websocket

[IMP] pos_mollie: remove blocking validation error

PR #260293

Core19.0pos_mollie

Configuring a Mollie payment method in Point of Sale is now smoother because users can save the setup before entering the API key on the related payment provider. This avoids having to re-enter form details, while payments will still be blocked if the API key is missing at payment time.

Original PR description

Before this commit, when configuring the Mollie payment method in POS, a validation error would be raised if the associated payment provider did not have the API key set. While this makes sense given that it needs to be set in order for payments to work, it resulted in this unintuitive UX:

1. User fills in all the fields in the Mollie POS payment method form.
2. The user tries to save, but hits the validation error.
3. The user uses the internal link to go to the payment provider and fill in the API key.
4. The user returns to the POS payment method form, but because the form couldn't save they have to fill in everything *again*.

This commit removes the validation error, allowing everything to be filled in just once. There will still be an error if trying to make a payment without an API key set.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#point-of-sale#mollie#payment-setup#user-experience

This case induces confusion in the ranks: when the WS connection fails, the result of the run is set to failure then every outstanding response is cancelled. For `_wait_ready` specifically, because it's a blocking wait on a request it yield a confusing result as the run fails with `CancelledError` and the actual cause (the WS was closed) is lost. One option would be to `set_exception` on the waiting responses, but I feel like this could create other confusing knock-on effects e.g. more evented waits which currently get ignored might start raising exceptions (although that seems unlikely as callbacks apparently do get called on cancel), and since issues with cancelling only seem to appear in `_wait_ready` that seems like overkill. Instead have `_wait_ready` handle cancellation by first checking if the result is in error, and using that to raise the underlying error, otherwise retry (and ultimately timeout, probably). And while at it, before signaling a timeout check if the run is in failure and raise that immediately, just in case. https://runbot.odoo.com/odoo/error/233738 Forward-Port-Of: odoo/odoo#260324

Before this commit, when configuring the Mollie payment method in POS, a validation error would be raised if the associated payment provider did not have the API key set. While this makes sense given that it needs to be set in order for payments to work, it resulted in this unintuitive UX: 1. User fills in all the fields in the Mollie POS payment method form. 2. The user tries to save, but hits the validation error. 3. The user uses the internal link to go to the payment provider and fill in the API key. 4. The user returns to the POS payment method form, but because the form couldn't save they have to fill in everything *again*. This commit removes the validation error, allowing everything to be filled in just once. There will still be an error if trying to make a payment without an API key set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr