Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2020-10-05 11:402021-01-28 13:20
ReporterrafarodaView Statuspublic 
Assigned Toranjith_qualiantech_com 
PrioritynormalResolutionfixedFixed in VersionRR21Q1
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0045188: Incremental Refresh fail: continues the load when it should stop

DescriptionIncremental Refresh fail: continues the load when it should stop
Steps To ReproduceHave a failed Incremental refresh: because of timeout for instance

Incremental refresh continues with the load of the rest of models, that could lead to inconsistent states:
* For instance, if Product model failed
* Product Characteristics Values could be orphan

Or it can be confusing for the user that does not understand when a Promo is missing, see 0044662
Proposed SolutionStop the Incremental refresh load if something fails? Or other solution: for sure this is confusing for the user since unless it checks the Chrome Console he won't know that something did not load
Attached Filesdiff file icon 45188_20Q3._mobilecore.diff [^] (1,865 bytes) 2021-01-28 13:20 [Show Content]

- Relationships Relation Graph ] Dependency Graph ]
related to defect 0045187 closedranjith_qualiantech_com Full Refresh fail: continues the load when it should stop 
related to defect 0044662 closedranjith_qualiantech_com Discounts are not updated on webpos after incremental refresh 
related to defect 0045155 closedRetail Discount and promotion- Removing filters are not sent to WebPOS 
related to defect 0045154 closedranjith_qualiantech_com Discount and promotion - Filter change are not sent to WebPOS 
related to defect 0045153 closedranjith_qualiantech_com Discount and promotion - Disabling organizations are not sent to WebPOS 
related to defect 0045834 closedranjith_qualiantech_com When an incremental refresh fails, the field 'Channel - Touchpoint || Incremental Refresh Masterdata Load' is updated 
related to defect 0045842 closedranjith_qualiantech_com Confused message when the Full Refresh fails 
related to defect 0045852 closedranjith_qualiantech_com Wrong behaviour when the browser is closed before Full Refresh finishes 
related to defect 0045879 closedranjith_qualiantech_com Full refresh does not restar after F5 in all the cases 

-  Notes
rafaroda (developer)
2020-10-05 12:06

See related 0045187
hgbot (developer)
2020-10-14 07:54

Merge Request created: [^]
hgbot (developer)
2020-10-29 16:06

Directly closing issue as related merge request is already approved.

Repository: [^]
Changeset: b1913ba35d19c69af2a18dc785ccefdf18e04133
Author: Ranjith S R <>
Date: 2020-10-29T15:06:31+00:00
URL: [^]

Fixed ISSUE-45188: Prevent Subsequent request when MasterData request fails
* For Incremental & Full refresh, Masterdata for models should be updated only when all masterdata request are success

M web/
hgbot (developer)
2020-10-29 16:06

Merge request merged: [^]
marvintm (developer)
2020-10-29 16:10

Just to clarify: the change done ensures that once a request has failed, subsequent requests will not be triggered.

In case of full refresh, the user will be then prompted to restart the refresh again, as database is recreated every time full refresh is done, so all subsequent entities will be missing.

In case of incremental refresh, the WebPOS automatically navigates to the main window in offline mode after previous models have been updated.

It is indeed possible that inconsistencies in masterdata may happen. However, it is not possible for us to prevent this (as data needs to be downloaded in chunks, and cannot be inserted or updated "transactionally" due to the fact that neither IndexedDB provides an API capable of doing this while Ajax requests are done, nor we have enough memory to keep all loaded data before actually inserting it).

- Issue History
Date Modified Username Field Change
2020-10-05 11:40 rafaroda New Issue
2020-10-05 11:40 rafaroda Assigned To => Retail
2020-10-05 11:40 rafaroda Resolution time => 1603144800
2020-10-05 11:40 rafaroda Triggers an Emergency Pack => No
2020-10-05 11:40 rafaroda Issue generated from 0045187
2020-10-05 11:40 rafaroda Relationship added related to 0045187
2020-10-05 11:40 rafaroda Tag Attached: NOR
2020-10-05 11:41 rafaroda Relationship added related to 0044662
2020-10-05 11:41 rafaroda Relationship added related to 0045155
2020-10-05 11:41 rafaroda Relationship added related to 0045154
2020-10-05 11:42 rafaroda Relationship added related to 0045153
2020-10-05 12:06 rafaroda Note Added: 0123528
2020-10-09 11:50 ranjith_qualiantech_com Assigned To Retail => ranjith_qualiantech_com
2020-10-09 11:50 ranjith_qualiantech_com Status new => scheduled
2020-10-14 07:54 hgbot Note Added: 0123669
2020-10-29 16:06 hgbot Resolution open => fixed
2020-10-29 16:06 hgbot Status scheduled => closed
2020-10-29 16:06 hgbot Fixed in Version => RR21Q1
2020-10-29 16:06 hgbot Note Added: 0124018
2020-10-29 16:06 hgbot Note Added: 0124019
2020-10-29 16:10 marvintm Note Added: 0124021
2021-01-28 13:20 ranjith_qualiantech_com File Added: 45188_20Q3._mobilecore.diff
2021-02-02 13:01 rafaroda Relationship added related to 0045834
2021-02-03 16:56 rafaroda Relationship added related to 0045842
2021-02-04 12:49 rafaroda Relationship added blocks 0045852
2021-02-04 12:49 rafaroda Relationship deleted blocks 0045852
2021-02-04 12:50 rafaroda Relationship added related to 0045852
2021-02-10 14:47 rafaroda Relationship added related to 0045879

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker