Openbravo Issue Tracking System - Retail Modules
View Issue Details
0046284Retail ModulesWeb POSpublic2021-04-16 09:442021-04-20 17:21
marvintm 
gorka_gil 
normalmajorhave not tried
closedfixed 
5
 
RR20Q4.4RR20Q4.4 
marvintm
Production - Confirmed Stable
2020-04-06
RR20Q3
https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/00f799553369f73469ee678dcede357c099d5032 [^]
No
0046284: Full refresh should be executed every time there are model changes, but sometimes it doesn't happen
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.
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.
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).
No tags attached.
blocks defect 0046280 closed gorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 
Issue History
2021-04-16 12:51marvintmTypedefect => backport
2021-04-16 12:51marvintmTarget Version => RR20Q4.4
2021-04-20 17:16hgbotResolutionopen => fixed
2021-04-20 17:16hgbotStatusscheduled => resolved
2021-04-20 17:16hgbotFixed in Version => RR20Q4.4
2021-04-20 17:16hgbotNote Added: 0127399
2021-04-20 17:17gorka_gilAssigned ToRetail => gorka_gil
2021-04-20 17:17gorka_gilReview Assigned To => marvintm
2021-04-20 17:21marvintmStatusresolved => closed

Notes
(0127399)
hgbot   
2021-04-20 17:16   
Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^]
Changeset: 1f5926ef8c5c30730f184df6945d3ac2b973fce3
Author: Gorka Gil <gorka.gil@openbravo.com>
Date: 2021-04-20T17:16:25+02:00
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/1f5926ef8c5c30730f184df6945d3ac2b973fce3 [^]

Fixes ISSUE-46284: Fix random missing full refresh

There is a race condition in the request of login utils,
that doesn't wait for get the db hashes (current.backend),
and starts checking for changes in the models

So we have correctly the:
- persisted.frontend (indexes, etc) - saved in localstoraged
- persisted.backend (properties-columns, etc) - saved in localstoraged
- current.frontend - calculated from the sources
We are missing:
- current.backend - done in a request to login utils, that is async and we don't wait for it

In this case,
- for check diferences: we only check the frontend , since is missing the current.backend
- there isn't detected any differences, but the current are saved, which overwrite the persisted.backend with null

Changed to
- Only save the current into persisted if there is changes and if current.frontend and current.backend are present

---
M web/org.openbravo.mobile.core/app/model/masterdata/MasterdataController.js
---