Florian CharlierandJulien Castiaux
beaae001f8
and better handle progress requests. In previous versions, it sometimes occurred that multiple onboarding_progress records were created despite our measures against that. Two problems were identified and fixed here, together with a simple mean to handle this error on the client-side. 1. `_sql_constraints` entry was not adequate to prevent multiple records from being created for onboardings which are not to be completed per-company but per database because in our version(s) of PostgreSQL `NULL` values cannot be considered `NOT DISTINCT`, i.e., all NULL values are different from one another so `UNIQUE` is respected when we wouldn't want it. Therefore, we implement here a `UNIQUE` index via the model's init, allowing to catch unique violations when company_id is not set. 2. While we search if a record exists before creating a new one, it could happen that another worker created a record between these steps. As the database is configured (`REPEATABLE_READ`, which applies until the end of the transaction, when we leave the controller), it is very difficult to retrieve the record created by the other process. See additional details in the testing part below. Therefore, we chose to ask the client to perform a new request if desirable. Existing extra records are removed with the related UPG PR script. ### Tests Tests are included to make sure it is not possible to create multiple onboarding_progress records for the same onboarding and company or without any. This includes a non-standard (runbot will not run it) and "database breaking" (we try to clean up our mess but we cannot give any guarantee) concurrent test that reproduce the following scenario: The `/onboarding/<string:route_name>` is called twice in two different workers for a same `route_name`. The corresponding onboarding exists and has no corresponding `onboarding.progress` record yet. Python side, the two workers are oblivious of what's happening in the transaction of the other worker thus any python-side-only unicity constraint would fail to detect any progress created by other workers. This would end up with two progress records created for a single onboarding which is illegal. Task-3101666 closes odoo/odoo#109221 Related: odoo/upgrade#4142 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
6 lines
172 B
Python
6 lines
172 B
Python
# -*- coding: utf-8 -*-
|
|
# Part of Odoo. See LICENSE file for full copyright and licensing details.
|
|
|
|
from . import test_onboarding
|
|
from . import test_onboarding_concurrency
|