|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Retail Modules] Web POS||major||have not tried||2021-04-16 09:44||2021-04-20 17:06|
|Priority||normal||Resolution||fixed||Fixed in Version||RR21Q3|
|Status||closed||Fix in branch||Fixed in SCM revision|
|OS Version||Database version||Ant version|
|Product Version||SCM revision|
|Review Assigned To||marvintm|
|Regression level||Production - Confirmed Stable|
|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||No|
0046280: 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).
|Tags||No tags attached.|
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/209 [^]
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/214 [^]
|The race condition is very complex to prevent. However, there is no need actually, as when new sources are deployed, a refresh is automatically done (due to the JS sources actually changing), so in the end the full refresh is triggered (after the second problem is fixed, by making the hash checking code more robust)|
Directly closing issue as related merge request is already approved.
Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^]
Author: Gorka Gil <email@example.com>
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/bb1bcb5995dc2966ba644ad7a7ec18114ba6f4fc [^]
Fixes ISSUE-46280: 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
- Only save the current into persisted if there is changes and if current.frontend and current.backend are present
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/214 [^]
|2021-04-16 09:44||marvintm||New Issue|
|2021-04-16 09:44||marvintm||Assigned To||=> Retail|
|2021-04-16 09:44||marvintm||Triggers an Emergency Pack||=> No|
|2021-04-16 09:47||marvintm||Steps to Reproduce Updated||View Revisions|
|2021-04-16 09:47||marvintm||Proposed Solution updated|
|2021-04-16 10:11||marvintm||Relationship added||related to 0046187|
|2021-04-16 12:45||marvintm||Regression level||=> Production - Confirmed Stable|
|2021-04-16 12:45||marvintm||Regression date||=> 2020-04-06|
|2021-04-16 12:45||marvintm||Regression introduced in release||=> RR20Q3|
|2021-04-16 12:45||marvintm||Regression introduced by commit||=> https://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/00f799553369f73469ee678dcede357c099d5032 [^]|
|2021-04-16 12:51||marvintm||Status||new => scheduled|
|2021-04-16 13:27||hgbot||Note Added: 0127310|
|2021-04-20 14:47||hgbot||Note Added: 0127387|
|2021-04-20 16:31||marvintm||Note Added: 0127391|
|2021-04-20 16:32||hgbot||Resolution||open => fixed|
|2021-04-20 16:32||hgbot||Status||scheduled => closed|
|2021-04-20 16:32||hgbot||Fixed in Version||=> RR21Q3|
|2021-04-20 16:32||hgbot||Note Added: 0127392|
|2021-04-20 16:32||hgbot||Note Added: 0127393|
|2021-04-20 16:53||gorka_gil||Status||closed => new|
|2021-04-20 17:00||gorka_gil||Status||new => scheduled|
|2021-04-20 17:04||gorka_gil||Status||scheduled => resolved|
|2021-04-20 17:04||gorka_gil||Status||resolved => closed|
|2021-04-20 17:06||marvintm||Assigned To||Retail => gorka_gil|
|2021-04-20 17:06||marvintm||Review Assigned To||=> marvintm|
|Copyright © 2000 - 2009 MantisBT Group|