fix: create-missing-variants search on Odoo 19 + e2e registry reload#215
Conversation
Two fixes that make the nightly e2e integrity workflow green again (it was
failing on Odoo 16/17/19; 18 passed). Both surfaced only through the single
tests/e2e/test_variant_workflow scenario.
- variant_manager: filter templates on the ``product_variant_ids`` relation
instead of ``product_variant_count``. The count is a non-stored computed field
and Odoo 19 rejects it in a search domain ("Cannot convert ... to SQL because
it is not stored"); the one2many is a real relational field, so "no variants"
is expressible across all versions. Fixes create-missing-variants on Odoo 19
for real users, not just the test. Unit-test assertion updated to match.
- e2e harness: restart the Odoo service after the ``product_module`` fixture
installs ``product`` mid-session. The long-running server caches target_db's
(base-only) registry the first time it serves it, and a separate
``-i product --stop-after-init`` install does not reliably make it reload
(Object product.template doesn't exist on Odoo 16/17). A restart clears the
in-memory registry cache so the next request rebuilds it with product.
Verified: full ``-m "not large"`` suite passes on fresh Odoo 16, 17, 18 and 19
(19/19 each).
There was a problem hiding this comment.
Code Review
This pull request updates the search domains in variant_manager.py to filter on the product_variant_ids relation instead of the non-stored computed field product_variant_count, preventing search errors in Odoo 19. Additionally, it introduces a helper function to restart service containers in E2E tests, ensuring the Odoo registry cache is cleared and rebuilt after mid-session module installations. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
pydoclint's rendering of the 'batch' and 'odoo_endpoint' DOC404 yield types drifted (Any -> list[Any], (str, object) -> dict[str, object]) with the current resolved toolchain, so the committed baseline no longer matched and the pydoclint pre-commit hook failed. Update just those two lines to the current rendering. No source change.
3ebc56e to
2d0252f
Compare
What
Makes the nightly End-to-End Integrity Tests workflow green again. It has been failing on Odoo 16/17/19 (18 passed) — all from the single
tests/e2e/test_variant_workflow.pyscenario, which broke two different ways:1. Odoo 19 — real product-code bug
variant_managersearched templates onproduct_variant_count, a non-stored computed field. Odoo 19 rejects it in a search domain:Fix: filter on the
product_variant_idsone2many (a real relational field), which expresses "no variants" across all Odoo versions. This fixescreate-missing-variantson Odoo 19 for real users, not just the test. The unit-test assertion is updated to match.2. Odoo 16/17 — e2e harness registry-reload gap
The
product_modulefixture installsproductmid-session via a separate-i product --stop-after-initprocess, but the long-running server had already cachedtarget_db's (base-only) registry from earlier tests and didn't reload it:Fix: restart the Odoo service after the install (
_runtime.restart_service+wait_http_ready) so the next request rebuilds the registry withproduct. Proved directly:product.templatefailed before the restart and succeeded after.Verification
Ran the full
-m "not large"suite against a fresh managed stack on Odoo 16, 17, 18 and 19 — 19 passed on every version. Unit suite: 1431 passed.Files
src/fluvo/lib/actions/variant_manager.py— search the relation, not the count (2 sites)tests/test_variant_manager.py— assertion updatedtests/e2e/_runtime.py—restart_servicehelpertests/e2e/conftest.py— restart + wait after mid-session product install