Openbravo Issue Tracking System - POS2
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0049874POS2POSpublic2022-07-24 19:212022-08-23 14:40
Reporterguilleaer 
Assigned ToRetail 
PrioritynormalSeveritycriticalReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target Version22Q3Fixed in Version 
Merge Request Status
Review Assigned ToAugustoMauch
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0049874: A mechanism to detect incorrect state recovery from persistence layer is required
DescriptionAfter investigating some sequence breaks in customer production environment we suspect that sometimes the state recovery from persistence layer to the state (when f5 is done) is not working well.
Because of that, the sequence stored in the terminal object is greater than the sequence recovered in the state and the sequence of the terminal overwrites the one from the state


State 20
Terminal 20

Sale 1
State 21
Terminal 20

Sale 2
State 22
Terminal 20

f5 is pressed
For some reason a preious state is recovered an now is the new state
State 19
Terminal 20

In this situation a pieze of code is executed. Since terminal is > to state the new seq in the state is 20

Sale 3
State 20
Terminal 20

DUPLICATED!

Sale 4
State 22
Terminal 20

DUPLICATED!


To be able to find more information we need a mechanism to ensure that the state that we recover is the same state that we saved lastly
Steps To ReproduceN/A
Proposed SolutionWhen an order is completed generate a unique UUID in one model which is persisted (docSequence)
When the state is recovered form persistance layer -> log the recovered ID

If we found cases in which the recovered UUID is different from the Last saved UUID then we know that we have a problem in the process to save/restore the state
Additional Information
TagsNo tags attached.
Relationships
blocks feature request 0049873 closed guilleaer A mechanism to detect incorrect state recovery from persistence layer is required 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2022-07-24 19:31guilleaerTypefeature request => backport
2022-07-24 19:31guilleaerTarget Version => 22Q3
2022-08-16 12:58marvintmTarget Version22Q3 => 22Q3.1
2022-08-23 14:38guilleaerNote Added: 0140323
2022-08-23 14:39guilleaerNote Added: 0140324
2022-08-23 14:40guilleaerTarget Version22Q3.1 => 22Q3
2022-08-23 14:40guilleaerStatusscheduled => resolved
2022-08-23 14:40guilleaerResolutionopen => fixed
2022-08-23 14:40guilleaerReview Assigned To => AugustoMauch
2022-08-23 14:40guilleaerStatusresolved => closed

Notes
(0140323)
guilleaer   
2022-08-23 14:38   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.core2 [^] [^]
Changeset: 1a63cd4b120bd7656ae7b8d6017b360a86f6498c
Author: Guillermo Alvarez de Eulate <guillermo.alvarez@openbravo.com>
Date: 03-08-2022 14:29:04
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/commit/1a63cd4b120bd7656ae7b8d6017b360a86f6498c [^] [^]

Fixes ISSUE-49873: Adds a hook to be executed when the state is recovered from the persistence layer

---
M web-jspack/org.openbravo.core2/src/core/Registry.js
M web-jspack/org.openbravo.core2/src/ob-init.js
---
(0140324)
guilleaer   
2022-08-23 14:39   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2 [^] [^]
Changeset: 670693674732d742d61ba27292fe89a99f438d34
Author: Guillermo Alvarez de Eulate <guillermo.alvarez@openbravo.com>
Date: 03-08-2022 14:29:38
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/commit/670693674732d742d61ba27292fe89a99f438d34 [^] [^]

Fixes ISSUE-49873: Write in log latest assigned sequence number when state is recovered from persistence layer

---
M web-jspack/org.openbravo.pos2/src/ob-init.js
---