Skip to content

Fork Sync Branch 18.0 - #220

Merged
btl-bot merged 6 commits into
BTLzdravtech:18.0from
OCA:18.0
Sep 17, 2026
Merged

btl-bot merged 6 commits into
BTLzdravtech:18.0from
OCA:18.0

Conversation

@btl-bot

@btl-bot btl-bot commented Sep 17, 2026

Copy link
Copy Markdown

No description provided.

florian-dacosta and others added 6 commits September 11, 2026 00:48
detect_exceptions() stores the exceptions in a separate transaction (a new
cursor/connection) so that they are kept when the ongoing transaction is
rolled back. When the registry is not ready yet (module installation or
update), the ongoing transaction holds exclusive locks on the tables it has
just modified (ALTER TABLE ...). The call to
_must_raise_exception_after_detection() made inside that new transaction then
reads the model records, and the query waits for those locks forever: the
only thread able to release them is the one waiting for them.

This happens as soon as demo data confirming a sale order is loaded during a
database initialisation with sale_exception installed (e.g. the sale_stock
demo data), making the whole database initialisation hang.

Use the current cursor in that case, as already done when running tests.
Signed-off-by hparfr
…transaction

detect_exceptions() opens a second, genuinely independent DB connection
(self.env.registry.cursor()) to write exception flags so they survive a
rollback of the ongoing transaction. It then re-derived main_records
through that same second connection (self.with_env(new_env)), which
crashes with MissingError whenever _get_main_records() has to read a
field on records created earlier in the SAME ongoing transaction and not
yet committed (e.g. sale.order.line._get_main_records() reading order_id
right after the line was created by write()).

Typical trigger: adding a product to an already confirmed sale order.
sale_exception.write() re-runs detect_exceptions() on order_line whenever
order_line changes on a confirmed order; the new line only exists in the
ongoing transaction, so the second connection can't see it yet.

Resolve main_records once through the original (main) cursor, which does
see the just-created records, and only rebind that already-resolved
recordset to the new environment for the exception_ids check.
Signed-off-by hparfr

@sireko sireko left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto approved

@btl-bot
btl-bot merged commit 23a3071 into BTLzdravtech:18.0 Sep 17, 2026
3 of 4 checks passed
@codecov-commenter

Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Files with missing lines Coverage Δ
base_exception/models/base_exception_method.py 80.80% <100.00%> (+0.19%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants