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

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0046280
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajorhave not tried2021-04-16 09:442021-04-20 17:06
ReportermarvintmView Statuspublic 
Assigned Togorka_gil 
PrioritynormalResolutionfixedFixed in VersionRR21Q3
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
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

0046280: 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 ]
related to defect 0046187 closedranjith_qualiantech_com WebPOS triggered unexpected Full Refresh 
depends on backport 0046282RR21Q2.1 closedgorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 
depends on backport 0046283RR21Q1.2 closedgorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 
depends on backport 0046284RR20Q4.4 closedgorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 
depends on backport 0046310RR20Q3.4 closedgorka_gil Full refresh should be executed every time there are model changes, but sometimes it doesn't happen 

-  Notes
(0127310)
hgbot (developer)
2021-04-16 13:27

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/209 [^]
(0127387)
hgbot (developer)
2021-04-20 14:47

Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/214 [^]
(0127391)
marvintm (developer)
2021-04-20 16:31

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)
(0127392)
hgbot (developer)
2021-04-20 16:32

Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^]
Changeset: bb1bcb5995dc2966ba644ad7a7ec18114ba6f4fc
Author: Gorka Gil <gorka.gil@openbravo.com>
Date: 2021-04-20T14:31:40+00:00
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

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
---
(0127393)
hgbot (developer)
2021-04-20 16:32

Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/214 [^]

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker