OMS timeout API inconsistency
So, I was doing some micro-optimizations and noticed that:
\Spryker\Zed\Oms\Business\OrderStateMachine\Timeout::dropOldTimeouts
works differently than\Spryker\Zed\Oms\Business\OrderStateMachine\Timeout::dropOldTimeout
where dropOldTimeout (singular) checks if the source state has a timeout event and drops it if it does, dropOldTimeouts (plural) check if source AND target states have timeout events and drops only if both do.
I don't know if the latter logic makes much sense in most use cases 🤔
Answers
-
Hi, Mikko!
That's an interesting finding.
I cannot suggest, which option is more correct, so if you find some bug caused by this inconsistency, please report it in the OMS module on GitHub.
I can assure you, that both versions of the code will create a timeout, when needed.
And by the nature of the timeout processing, if there's a timeout that's happening for the item in the wrong state, we just skip it as a faulty.
AndriyT
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 69 Spryker News
- 896 Developer Corner
- 758 Spryker Development
- 83 Spryker Dev Environment
- 361 Spryker Releases
- 3 Oryx frontend framework
- 34 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 23 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 68 Spryker Safari Questions
- 50 Random