0039264: In some circumstances, cashup may be synchronized twice and the second one generates entry in "Errors while importing POS data"

Openbravo Issue Tracking System - Retail Modules

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0039264

Retail Modules

Web POS

public

2018-08-03 15:01

2018-09-18 18:16

Reporter

marvintm

Assigned To

migueldejuana

Priority

high

Severity

major

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

RR18Q3.1

Fixed in Version

RR18Q3.1

Merge Request Status

Review Assigned To

marvintm

OBNetwork customer

OBPS

Support ticket

3805

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0039264: In some circumstances, cashup may be synchronized twice and the second one generates entry in "Errors while importing POS data"

Description

In some circumstances, the cashup may be synchronized twice. The first time it will be processed correctly, but the second time detects that the cashup was already processed, and therefore generates an Error while importing POS Data.

Steps To Reproduce

- Go to the cashup window.
- Go through all steps to complete the cashup.
- Before clicking on "Post, print and close" button, add a breakpoint in the client side, in the line:

"OB.RR.ServTypeFailover.implementation(service, request);"

- Click on the button. Flow will continue until the line with the breakpoint.
- Execute that line, but not the rest of the flow. The request will be done, and the cashup will be processed in the backend. This is correct.
- Then, press F5, or close the browser, and then access the WebPOS again.
- Once you have logged in, you will see that the cashup has already been sent again, and this time it has failed.

Real customers are reproducing this problem very rarely, with slow computers, and by closing the browser before the process to complete the cashup has been fully executed.

Proposed Solution

The problem is that the generation of the message and the deletion of the cashup is still not fully transactional.

We need to make sure that both the message generation and the cashup deletion are executed in the same database transaction, but also before the request is triggered, because otherwise there is a risk that the deletion may not happen before the request is done, and even if the message is not generated, the cashup has already arrived to the backend, and should have already been removed from the client side.

Additional Information