Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0046284 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
backport | [Retail Modules] Web POS | major | have not tried | 2021-04-16 09:44 | 2021-04-20 17:21 | |||
Reporter | marvintm | View Status | public | |||||
Assigned To | gorka_gil | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | RR20Q4.4 | |||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | RR20Q4.4 | |||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Review Assigned To | marvintm | |||||||
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 | No | |||||||
Summary | 0046284: 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. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | ||||||||
|
Notes | |
(0127399) hgbot (developer) 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 --- |
Issue History | |||
Date Modified | Username | Field | Change |
2021-04-16 12:51 | marvintm | Type | defect => backport |
2021-04-16 12:51 | marvintm | Target Version | => RR20Q4.4 |
2021-04-20 17:16 | hgbot | Resolution | open => fixed |
2021-04-20 17:16 | hgbot | Status | scheduled => resolved |
2021-04-20 17:16 | hgbot | Fixed in Version | => RR20Q4.4 |
2021-04-20 17:16 | hgbot | Note Added: 0127399 | |
2021-04-20 17:17 | gorka_gil | Assigned To | Retail => gorka_gil |
2021-04-20 17:17 | gorka_gil | Review Assigned To | => marvintm |
2021-04-20 17:21 | marvintm | Status | resolved => closed |
Copyright © 2000 - 2009 MantisBT Group |