Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
ID | ||||||||||||
0057652 | ||||||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
defect | [Modules] Advanced Warehouse Operations | major | always | 2025-01-15 17:24 | 2025-01-20 10:52 | |||||||
Reporter | malsasua | View Status | public | |||||||||
Assigned To | AtulOpenbravo | |||||||||||
Priority | high | Resolution | open | Fixed in Version | ||||||||
Status | new | Fix in branch | Fixed in SCM revision | |||||||||
Projection | none | ETA | none | Target Version | ||||||||
OS | Any | Database | Any | Java version | ||||||||
OS Version | Database version | Ant version | ||||||||||
Product Version | SCM revision | |||||||||||
Regression date | ||||||||||||
Regression introduced by commit | ||||||||||||
Regression level | ||||||||||||
Review Assigned To | ||||||||||||
Regression introduced in release | ||||||||||||
Summary | 0057652: Push API is sending DO in Ongoing status | |||||||||||
Description | When a distribution order is created and completed from AWO app, an EDL Request is created using the event OBDOAPI_UpdateDOStatus , but sometimes, the record is sent in status OnGoing It should not be possible because the DO are created in OnGoing status directly in the Frontend. Analyzing the code, we have seen the event only is triggered when the DO is processed, but we have some cases that the json sent from EDL Request contains docStatus=OnGoing | |||||||||||
Steps To Reproduce | . it happens randomly | |||||||||||
Tags | No tags attached. | |||||||||||
Attached Files | ||||||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
Notes | |
(0174198) vmromanos (manager) 2025-01-15 17:37 |
@Developer: In theory the launch of this event is centralized in the UpdateDOStatusEvent AfterDistributionOrderProcessedHook class, which is executed only after processing the DO (and therefore changing its status). See ProcessDistributionOrderUtil.processDistributionOrder() The ongoing status is not changed through this method, but instead the DO is synchronized directly with the Ongoing status. In theory this event shouldn't be launched for a DO in that status. After a quick view to the code I don't find the root cause. My first idea was related to the asynchronous nature of the push API events. But this shouldn't be a problem in this concrete case because the DO sent is in ongoing status, which shouldn't be possible from the application as explained above. The only possibility I see is that someone has changed the status back to ongoing after processing the DO, which is something impossible from the UI, and very weird from the user perspective. Because of that my recommendation would be to add log in the UpdateDOStatusEvent to print the stack trace and the DO information when we detect the DOi is in ongoing status to try to understand the root cause if we are unable to reproduce it ourselves. |
Issue History | |||
Date Modified | Username | Field | Change |
2025-01-15 17:24 | malsasua | New Issue | |
2025-01-15 17:24 | malsasua | Assigned To | => Triage Omni WMS |
2025-01-15 17:27 | vmromanos | Description Updated | View Revisions |
2025-01-15 17:37 | vmromanos | Note Added: 0174198 | |
2025-01-20 10:52 | mtaal | Assigned To | Triage Omni WMS => AtulOpenbravo |
Copyright © 2000 - 2009 MantisBT Group |