[FIX] web_calendar: fix read_slice race condition

When quickly changing the range in the calendar view, multiple
asynchronous read_slice requests will be launched. The read_slice
returns the records and sets the ids property on the dataset according
to a set domain, context etc.

This creates a race condition because although the read_slice calls will
be launched in the correct order, there is no guarantee that they will
resolve in the correct order. In practice issues will occur quite
frequently on a slower connection and with a big read followed by a
small read. The big read that matches a lot of records will be slower to
complete than the small read which will result in it resolving later
than the small read. This causes the dataset to not be in sync with the
rest of the view. When you click on an affected event everything will
look fine in the popup, but when clicking on edit the form view will
show a new event instead. The reason for this is that switching to the
form view requires a correct dataset.index, which is set by
dataset.get_id_index(id) which won't exist.

A potential way of fixing this would be guaranteeing the order of
read_slice calls by only allowing one of them to be active at a
time. This would not be ideal because you could end up with a long chain
of read_slice calls when changing the range fast on a slow
connection. In theory the UI would have to block as well then.

Instead of that, we will simply ignore responses to out-of-date
requests. This is done by manually resetting the ids property of the
dataset to its previous value when we detect the range of the calendar
has changed since the read_slice call was launched.

opw-673425

0 files changed, 0 insertions, 0 deletions