Calling Developers!
We are reenergizing our code contribution process! Learn More

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..

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

Options
michael.schmetter
michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet

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?

Comments

  • UKEP86J66
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    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
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    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
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    @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
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    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
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    @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
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    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
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    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
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    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
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    Did you try removing this part?

                <transition> <!-- else  -->
                    <source>paid</source>
                    <target>paid</target>
                </transition>
    
  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    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
    UKEP86J66 Posts: 208 🧑🏻‍🚀 - Cadet
    Options

    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.