OMS timeout API inconsistency

mikko.ropanen
mikko.ropanen Spryker Solution Partner Posts: 27 ✨ - Novice

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 🤔

Tagged:

Answers

  • profuel
    profuel Sprykee Posts: 55 🪐 - Explorer

    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