0046282: Full refresh should be executed every time there are model changes, but sometimes it doesn't happen

Openbravo Issue Tracking System - Retail Modules

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0046282

Retail Modules

Web POS

public

2021-04-16 09:44

2021-04-20 17:21

Reporter

marvintm

Assigned To

gorka_gil

Priority

normal

Severity

major

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

RR21Q2.1

Fixed in Version

RR21Q2

Merge Request Status

Review Assigned To

marvintm

OBNetwork customer

Support ticket

Regression level

Production - Confirmed Stable

Regression date

2020-04-06

Regression introduced in release

RR20Q3

Regression introduced by commit

https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/00f799553369f73469ee678dcede357c099d5032 [^]

Triggers an Emergency Pack

Summary

0046282: Full refresh should be executed every time there are model changes, but sometimes it doesn't happen

Description

Masterdata full refresh should be executed every time there are model changes. However, sometimes this doesn't happen. The problem happens randomly, and its trigger is a race-condition situation, however, there are two factors that combine to cause it.

- First factor is that we currently don't guarantee that the loginutils request (which retrieves the backend hashes) finishes before we start checking the hashes
- Second factor is that we always save the hashes in the local storage, even if we didn't recreate the database. This is problematic because in some scenarios, we don't actually check the backend hashes, so it could happen that we save the hashes data structure even if we missed the backend hashes, and this means that we would overwrite the hashes that we originally had when we created the database.

Steps To Reproduce

The combination of those two factors triggers the problem in the following way:
- In a clean scenario we access the application. Hashes are saved correctly, and full refresh is done. Logout
- We deploy a change in a model and restart Tomcat.
- We access the application again. If the race-condition happens, we will check the hashes BEFORE the new hashes have been loaded.
- In this case, we are missing the new hashes, so comparison is not done. However, the persisted hashes are OVERWRITTEN with the new hash structure (that is missing the backend hashes). At this point, we have lost the old hashes. As comparison is not done, full refresh is not done.
- If we then refresh the page (or login/logout), then we finally load the new hashes, and compare them. As we are missing persisted backend hashes, we return no changes, but we still overwrite the persisted hashes, which means that we have set the new hashes in the persisted hashes. Full refresh is not done.

At this point, we have completely lost the old hashes, new hashes have been persisted, but still, full refresh has not been done.

Proposed Solution

Two main changes need to be done:
- We need to try to prevent the race condition, ie. we need to try to ensure that the hashes are not checked until we finally load the new ones.
- We need to make the hash checking code more robust, with the following two changes:
* We should only overwrite the persisted hashes with the current ones if "changed" is true (it doesn't make sense to overwrite the reference hashes if the database is not recreated).
* We should only actually write the persisted hashes if the data structure is complete (ie. if it has both "frontend" part and "backend" part).

Additional Information