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

anyone else maybe had the problem, that states in the oms statemachine history log are duplicated an

U01BZ7Q3XRV
U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

anyone else maybe had the problem, that states in the oms statemachine history log are duplicated and so for example also mails are sent twice?

Comments

  • sebastian.larisch
    sebastian.larisch Spryker Customer Posts: 143 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited July 2022

    we had a problem with duplicate orders during our upgrade to 202109 which was caused by adding new plugins and still having old plugins in the dependency provider. not sure if we also had duplicates in order history. could b that u have sth similar. did u update any dependency provider like CheckoutDependencyProvider? maybe SalesDependencyProvider where OrderItemsPostSavePlugins are defined … just guesses. I would probably start debugging in \Spryker\Zed\Checkout\Business\Workflow\CheckoutWorkflow::placeOrder

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    the orders are not duplicated, and it only happens randomly sometimes, but maybe there is something that duplicates the execution under specific circumstances, thx

  • U03QLJ6GDSM
    U03QLJ6GDSM Posts: 2 πŸ§‘πŸ»β€πŸš€ - Cadet

    We had the same problem in a special case (where you have timeout and manual execution for the same event in your OMS process).

    We believe it has something to do with the Jenkins process check-oms-timeouts running for too long (in our case 3-4 minutes, while it was scheduled to run every minute).

    The process was running long because the spy_oms_event_timeout was full of old entries. It seems that if the item does not proceed in the OMS process (stays on the same state), the timeout won't be updated, and will be executed every time the scheduler runs the check-oms-timeouts process (and therefore clogs the system).

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    @U03QLJ6GDSM thanks for your insights. We actually had exactly the case where the table got so big that the job did not finish anymore because of memory_limit. I cleared the table of outdated entries and then it worked again and the rest of the table got cleared out by the jenkins job. But: I did not look into the table again if it is maybe a recurring problem

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    currently it contains only 7 entries. But maybe it have been more when the duplications happened. So I guess I should have a look at the run times of the jenkins job

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    wait... we changed to have 3 stores a while ago. And we have a jenkins job for each store for check oms conditions, but only one zed instance πŸ™ˆ oh dear god. Anyway thanks for getting me there

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    or does anyone know if the check.oms.condition filters by current store and only takes this orders?

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 πŸ§‘πŸ»β€πŸš€ - Cadet

    ah theres a command option for that