Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0053100Retail ModulesWeb POSpublic2023-07-28 14:342023-08-02 11:26
ReporterAugustoMauch 
Assigned ToAugustoMauch 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerNo
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0053100: SynchronizationBuffer.internalFlush does not flush all messages if some endpoints where currently syncing other messages
DescriptionThe internalFlush function of SynchronizationBuffer tries to synchronize all the messages from all the available endpoints. If an endpoint is already synchronizing previous messages, that endpoint will be skipped.

That function is invoked whenever new messages are added to the synchronization buffer, but also externally (i.e. to ensure all messages are synchronized before stopping the synchronization buffer when logging out).

It would be useful if, on demand, when internalFlush is executed and some endpoints are skipped because they were busy, it is recursively invoked a reasonable number of times until all messages are synchronized
Steps To ReproduceThis issue is difficult to reproduce, as it relies on a race condition (i.e. the backend endpoint being busy synchronizing terminal log messages when a user closes a cashup, resulting in the cashup not being synchronized until the next time the user logs in).

To help reproduce the issue:
- Install the attached sleepOnTerminalLog.diff patch. It contains commented out code that will result in the synchronized terminal log messages taking very long. Uncomment the code right after opening the cashup screen in pos2, if you do it before it will be difficult to use POS2.
- Open the Cashup window, move to the last step. Pay attention to the eclipse log, and the momento the "Sleeping" message is shown, complete the cashup. The user will be logged out, and if you check the synchronization buffer store in IndexedDB you will check that the message was not synchronized
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
depends on backport 0053131RR23Q1.4 closed AugustoMauch SynchronizationBuffer.internalFlush does not flush all messages if some endpoints where currently syncing other messages 
depends on backport 0053132RR23Q3 closed AugustoMauch SynchronizationBuffer.internalFlush does not flush all messages if some endpoints where currently syncing other messages 
depends on backport 0053133RR23Q2.3 closed AugustoMauch SynchronizationBuffer.internalFlush does not flush all messages if some endpoints where currently syncing other messages 
related to defect 0053139 closed AugustoMauch A message should be logged when SynchronizationBuffer.internalFlush gives after reaching max amount of retries 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2023-07-28 14:34AugustoMauchNew Issue
2023-07-28 14:34AugustoMauchAssigned To => AugustoMauch
2023-07-28 14:34AugustoMauchOBNetwork customer => No
2023-07-28 14:34AugustoMauchTriggers an Emergency Pack => No
2023-07-28 14:35AugustoMauchStatusnew => scheduled
2023-07-28 14:42AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=26538#r26538
2023-07-28 14:53hgbotMerge Request Status => open
2023-07-28 14:53hgbotNote Added: 0152983
2023-07-28 14:57hgbotNote Added: 0152984
2023-08-01 10:02hgbotNote Added: 0153049
2023-08-02 08:32AugustoMauchNote Deleted: 0152984
2023-08-02 08:32AugustoMauchNote Deleted: 0153049
2023-08-02 09:07hgbotMerge Request Statusopen => approved
2023-08-02 09:08hgbotResolutionopen => fixed
2023-08-02 09:08hgbotStatusscheduled => closed
2023-08-02 09:08hgbotNote Added: 0153088
2023-08-02 09:08hgbotFixed in Version => RR23Q4
2023-08-02 09:08hgbotNote Added: 0153089
2023-08-02 11:25AugustoMauchStatusclosed => new
2023-08-02 11:25AugustoMauchResolutionfixed => open
2023-08-02 11:25AugustoMauchFixed in VersionRR23Q4 =>
2023-08-02 11:26AugustoMauchStatusnew => scheduled
2023-08-02 11:26AugustoMauchStatusscheduled => resolved
2023-08-02 11:26AugustoMauchResolutionopen => fixed
2023-08-02 11:26AugustoMauchStatusresolved => closed
2023-08-02 14:01AugustoMauchRelationship addedrelated to 0053139

Notes
(0152983)
hgbot   
2023-07-28 14:53   
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/583 [^]
(0153088)
hgbot   
2023-08-02 09:08   
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/583 [^]
(0153089)
hgbot   
2023-08-02 09:08   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^]
Changeset: d7e84992f5c1ffe44bc8d163187d963a3fd3561c
Author: Augusto Mauch <augusto.mauch@openbravo.com>
Date: 02-08-2023 08:53:46
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/d7e84992f5c1ffe44bc8d163187d963a3fd3561c [^]

Fixes ISSUE-53100: SynchronizationBuffer.internalFlush does not ensure all messages are synchronized

Now, if the internalFlush method was executed and any of the endpoints were busy with previous synchronizations, it will be
recursively invoked after waiting for 500ms. The recursive calls will continue until none of the endpoints were busy or until
a maximum number of recursive calls (set to 10 for a total of a 5 second wait) is reached.

By default, internalFlush will behave as before, the new retry behaviour will only take place if its first param is passed to true

---
M web/org.openbravo.mobile.core/app/model/synchronization-buffer/SynchronizationBuffer.js
---