[18.0][FIX] base_exception: MissingError on records created in the ongoing transaction - #3725
Merged
OCA-git-bot merged 1 commit intoSep 15, 2026
Conversation
…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.
Contributor
|
Hi @hparfr, @sebastienbeau, |
1 task
Contributor
sergio-teruel
marked this pull request as ready for review
September 14, 2026 12:17
carlosdauden
approved these changes
Sep 14, 2026
Contributor
|
This PR looks fantastic, let's merge it! |
Contributor
|
Congratulations, your PR was merged at 60cd54e. Thanks a lot for contributing to OCA. ❤️ |
pedrobaeza
deleted the
18.0-fix-base_exception-uncommitted-record-cursor
branch
September 15, 2026 06:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
@Tecnativa TT64467
ping @carlosdauden @carlos-lopez-tecnativa