Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0046310
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Retail Modules] Web POSmajorhave not tried2021-04-16 09:442021-04-20 17:21
ReportermarvintmView Statuspublic 
Assigned Togorka_gil 
PrioritynormalResolutionfixedFixed in VersionRR20Q3.4
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget VersionRR20Q3.4
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Tomarvintm
Regression levelProduction - Confirmed Stable
Regression date2020-04-06
Regression introduced in releaseRR20Q3
Regression introduced by commithttps://code.openbravo.com/erp/pmods/org.openbravo.retail.posterminal/rev/00f799553369f73469ee678dcede357c099d5032 [^]
Triggers an Emergency PackNo
Summary

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

DescriptionMasterdata 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 ReproduceThe 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 SolutionTwo 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).
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
blocks defect 0046280 closedgorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 

-  Notes
(0127400)
hgbot (developer)
2021-04-20 17:18

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^]
Changeset: 0d19f150b499c2fbcda03aed0e5b95586341e7c2
Author: Gorka Gil <gorka.gil@openbravo.com>
Date: 2021-04-20T17:17:43+02:00
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/0d19f150b499c2fbcda03aed0e5b95586341e7c2 [^]

Fixes ISSUE-46310: 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-20 17:00 gorka_gil Type defect => backport
2021-04-20 17:00 gorka_gil Target Version => RR20Q3.4
2021-04-20 17:18 hgbot Status scheduled => closed
2021-04-20 17:18 hgbot Fixed in Version RR21Q3 => RR20Q3.5
2021-04-20 17:18 hgbot Note Added: 0127400
2021-04-20 17:18 gorka_gil Assigned To Retail => gorka_gil
2021-04-20 17:19 gorka_gil Review Assigned To => marvintm
2021-04-20 17:19 gorka_gil Status closed => new
2021-04-20 17:19 gorka_gil Fixed in Version RR20Q3.5 => RR20Q3.4
2021-04-20 17:19 gorka_gil Status new => scheduled
2021-04-20 17:19 gorka_gil Status scheduled => resolved
2021-04-20 17:21 marvintm Status resolved => closed

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker