Skip to content

Master owl3 migration 2 aku#5115

Draft
alexkuhn wants to merge 5 commits intomaster-owl3-migrationfrom
master-owl3-migration-2-aku
Draft

Master owl3 migration 2 aku#5115
alexkuhn wants to merge 5 commits intomaster-owl3-migrationfrom
master-owl3-migration-2-aku

Conversation

@alexkuhn
Copy link
Copy Markdown

No description provided.

This was no longer working with owl3 because the `onUpdate` in fields
were made to not observe their scope. The `onUpdate` of
`Rtc.callActions` is relying on `action.isActive` to manage the
stack, but `action.isActive` is not observed in `compute`.

This commit makes quick-fix to observe `action.isActive` in the
compute of field, so that the `onUpdate` can work as expected like
before. Note that this is not clean design, but this is the minimal
diff to keep it work.
Some tests and features were not passing, and these tests were
relying on effectWithCleanup(). This has been rewritten to make use
of newer `effect()` and disposeFn logic.
Test was relying on a re-order of sub-channel that was random.
There's no such re-order which is better, so test adapted to expect
no re-order.
@robodoo
Copy link
Copy Markdown

robodoo commented Apr 15, 2026

This PR targets the un-managed branch odoo-dev/odoo:master-owl3-migration, it needs to be retargeted before it can be merged.

Test "thread notifications are re-ordered on receiving a new message"
was not working:

This displays 2 conversations A and B in messaging menu. The preview
shows last message, and we expect when posting a new message the
message preview updates itself.

However this didn't update with the new message preview.

From investigation, `allMessages` is updated but not
`newestMessageOfAllMessages`. This is flagged as `computeInNeed` but
not `computeOnNeed` while not having updated the value. If we
re-trigger computation by hand this works.

The issue comes from using `immediateEffect` for both `compute` and
`sort` and using `stopFn` strategically to control the observe fn.
The code of compute with `immediateEffect` shows no problem: there's
an immediate effect that wasn't stopped and observe the compute
method, but somehow it's being unsubscribed as observer without any
call to dispose or from re-call of the effect.

The root cause of observer being removed actually comes from the
`stopFn` of `sort`: while `menuThreads` was sorting itself, it was
disposing the effect, and somehow it cancels "children" effects which
includes the compute effect and unsubscribe it completely.

This is weird: while this makes sense that some parts of compute's
effect can be disposed (the immediate dependency from sort's effect)
but that doesn't make sense to dispose completely the compute effect!
@alexkuhn alexkuhn force-pushed the master-owl3-migration-2-aku branch from 61a999c to 13c8fbb Compare April 17, 2026 18:00
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.

2 participants