What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello everyone 👋🏻, My team and I stumbled across the issue that on a `oms:check-ti

U023LUXS8MR
U023LUXS8MR Posts: 5 🧑🏻‍🚀 - Cadet
in Help

Hello everyone 👋🏻,

My team and I stumbled across the issue that on a oms:check-timeout command run, some items of an order change state whereas others in the same order only do in the next timeout check execution. Even stranger, the items transitioning last are those with lower Item-ID, hence the items that have been inserted into the database first. To our understanding, all items should transition to the next state in a single batch, since sharing the same process and source state, waiting for the same timeout and not being restricted by a condition or by-item command that would hinder an individual item’s progress in the state machine.

Did anyone else experience said issue of unintentionally split OMS transactions and know its cause? We already ruled out OMS misconfiguration regarding the OmsConfig::getCheckTimeoutsQueryLimit, which is set to null in our application, and are only relying on standard Spryker OMS features in the state where the split occurs (OMS Package Version 11.15.2). As a result, we consider there might be a bug in current OMS package regarding the timeout mechanism, where the evaluated timeout elapse checks may yield different results for individual items of the same transition batch, thus only allowing some of the items to advance.

Comments

  • U018XELUZS9
    U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet

    We had a similar problem, but with conditions, posted here: https://sprykercommunity.slack.com/archives/CKJRJM5FG/p1637084520140900

    We opened a case at Spryker and they confirmed that this is a bug. The OMS needs to be splitted in two areas: Run by order and run by order-item, which is currently not really possible.

  • U023LUXS8MR
    U023LUXS8MR Posts: 5 🧑🏻‍🚀 - Cadet

    Hi Alfred.

    Thank you for your answer 🙂. If I understand it correctly, we are both referring to still quite different scenarios in OMS. The thread you linked in your answer is related to order item batches being split due to an order item condition’s evaluation result changing mid-transition because of some asynchronous process (notification arrival, advancing of clock, etc.). In contrast, the problem we are currently facing seems to be related to the default OMS timeout handling routine, which has its own condition-independent implementation. Studies of the underlying source code suggest that all items should indeed transition in the same oms:check-timeout execution, but in our case they strangely do not on some rare occasions.

Categories