Good morning, short question regarding DB maintenance. I observed, that especially spy_oms_transitio

michael.schmetter

Good morning,
short question regarding DB maintenance.
I observed, that especially spy_oms_transition_log can grow quite big quite fast.
How do handle that?

UKEP86J66

Yes it can get big, because it tracks each state transition for each order item. However you should check for any “infinite loops” in your OMS state machines, which results in huge duplicates in the transition log.

UKEP86J66

We archive older orders to control the size of the sales/OMS tables but unfortunately this isn’t a generic process, it needs to be project specific due to all the relations with payments

michael.schmetter

@UKEP86J66
Thanks fit the answer!
We indeed have such kind of infinite loops like waiting for an external event (payment,...).
Is there a "nice" way to get rid of those?

UKEP86J66

We did have this problem a few years ago, the quick fix was writing some SQL to find particular duplicate states in a single order and remove the duplicates. Then we changed the state machine process to prevent the loops by either adding a retry count and escaping after a few tries or preventing the loop in the first place. For example if you need to wait for an external event it should be a check-condition transition and if the check fails there should be no transition, and therefore no log entry.

michael.schmetter

@UKEP86J66
I just checked, and at least in our case we got some rows for those "waitForSomething" conditions:

123,1,123,123,,Pyz\Zed\IsOrderPaidPlugin,,,host,,,|  |,vendor/bin/console oms:check-condition,1,waiting for payment,waiting for payment,2022-09-11 17:30:02

Do I miss anything here?

michael.schmetter

Or should I get rid of the second part, that we currently have?

            <transition happy="true" condition="MerchantSalesOrder/IsOrderPaid"> <!-- if all order items are paid  -->
                <source>paid</source>
                <target>merchant split pending</target>
            </transition>
            <transition> <!-- else  -->
                <source>paid</source>
                <target>paid</target>
            </transition>

UKEP86J66

The else condition looks strange because the source and target are the same - I think you can remove this part, because the “happy” transition will only change the state if the condition is true, otherwise it will remain in the “paid” state and there should be no entry in the log

michael.schmetter

Strange...
I double checked everything and TransitionLog is being written, even if source and target are the same.
I also cannot find anything that should prevent that in https://github.com/spryker/oms/blob/master/src/Spryker/Zed/Oms/Business/OrderStateMachine/OrderStateMachine.php

UKEP86J66

Did you try removing this part?

            <transition> <!-- else  -->
                <source>paid</source>
                <target>paid</target>
            </transition>

michael.schmetter

Yes i did.
The problem is:

<transition happy="true" condition="PSP/IsOrderPaid">
    <source>waiting for payment</source>
    <target>paid</target>
</transition>

This generates lines as:
23,5,441,576,,Pyz\Zed\PSP\Communication\Plugin\Oms\Condition\IsOrderPaidPlugin,,,87e094387bfe,,,| |,/data/vendor/bin/console oms:check-condition,1,waiting for payment,waiting for payment,2022-09-14 07:43:12

UKEP86J66

Strange - that doesn’t make sense to me. It’s my understanding that the log records transitions that complete but not ones that fail the condition. Our Spryker version does not do this but maybe we changed this behaviour, I do seem to remember checking the code for this area.