Issue with data not being saved in production with RoadRunner

[gabrielpeixoto]

Octane Version: 1.5.2 Laravel Version: 8.83.27 PHP Version: 8.2 Server & Version: RoadRunner 2.12.3 Database Driver & Version: Mysql 8.0.31-23

Description: I have recently switched to using RoadRunner as my server in production, and I have noticed that in some cases, data is not being saved to the database (Like an uncommitted transaction). For example, I have an API route that saves an object and returns its ID in the response. However, when I checked the database, the ID was not present (but the following ID was, which indicates that a rollback occurred).

I have tried to reproduce the issue locally, but I have not been successful. I am wondering if there is something misconfigured on my end that is causing this issue. Do you have any ideas of what could be causing this?

Steps To Reproduce (in my case):

1. Deploy the application with RoadRunner as the server.
2. Perform actions that involve writing data to the database, such as creating or updating records.
3. Check the database to see if the data was saved correctly.
4. In some cases, the data may not be saved, even though there are no errors reported.

[JackEllis]

@gabrielpeixoto Can you share the exact stuff you're doing in the request?

[nunomaduro]

Hey there,

Can you first please try one of the support channels below? If you can actually identify this as a bug, feel free to open up a new issue with a link to the original one and we'll gladly help you out.

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

Thanks!

[gabrielpeixoto]

@gabrielpeixoto Can you share the exact stuff you're doing in the request?

It's hard to say because that's when I put it into production I started seeing inconsistent data in the database and errors in the log.

I noticed errors in the application that occurred when users tried to access a database item by id that does not exist, and that id had been returned by some request to the user

[mayeenulislam]

We're confirming the same issue in a Larvel 9 (v9.11) Application. The row is been reverted without any log on the laravel.log.

Couldn't recreate the issue on the local server.

We're using:

• Laravel/Ocatne v1.2
• Spiral/Roadrunner v2.10

Don't have any clue why is this happening. After restarting/reloading the roadrunner the issue is been resolved - but don't know for how long.

Instead of discussing things on any private channel discussion and/or solution on a public Github issue would be great for us all. The issue is been closed here, but the issue is still present in some form. ☹️

[laravelbap]

I have same issue. Transactions are not committed. issue is on AWS with RoadRunner, 2 servers, Redis as cache.

[johnabil]

@gabrielpeixoto @nunomaduro Hello, I wanted to reopen this issue because i have the same problem with octane which is i have a service that creates orders with db transactions first so i noticed that multiple of my orders went missing instead I am sure 100% the order was created with sending email and notifications to the user with the full data of the order.

Laravel octane: v9.0
using swoole engine

[RubinhoSilva]

We have the same problem as Swoole and Octane "^2.1". No Docker, just Nginx as a proxy.

[indigoram89]

Have the same problem in production with Laravel v10.34.2 + Octane v2.1.2 + Swoole (Laravel Forge). We was checked everything and the only one reason is using Laravel Octane.

[johnabil]

@RubinhoSilva @indigoram89 Try first checking on Database locks if it has any deadlock maybe this is the reason not octane swoole

[indigoram89]

@johnabil Thank you for your advice, but it is not our case. One of our cases is some Queued Event Listener is not processing after event, but other listeners work fine:

ExampleEvent::class => [
    ExampleListenerOne::class,
    ExampleListenerTwo::class,
    ExampleListenerThree::class,
]

In this example ExampleListenerTwo not excecuted at all sometimes.

[DimitarDechew]

Having the same issue, but it is really strange for me. After running octane for some time (2-3h) the Passport OAuth token identifiers stop saving in the database, but when using the token Octane finds in in 80% of the requests and I don't know from where.

Tried debugging it, found temporary solution - reloading Octane seems to fix this problem, but I don't know how to localize the issue, because there are no other logs.

Was running: Laravel 9, Octane 1.5, Passport 10

Yesterday upgraded to (didn't test yet): Laravel 10, Octane 2.4, Passport 11

[totop275]

I have the same issue, not with Roadrunner but with Swoole. I've recently migrated from PHP-FPM to Laravel Octane using Swoole and noticed some strange behavior after running for a few days. Users with valid Sanctum tokens suddenly had their tokens marked as invalid, but when resending the token, it became valid again, then invalid, seemingly at random. The same thing happened when creating data—it would appear and disappear randomly. However, from the CMS, the data seemed fine.

I suspect this is related to Octane's stateful nature and its handling of database connections. Since Octane workers keep connections alive, an open transaction might cause all queries to go through that transaction. My Octane setup uses 4 workers, each with its own MySQL connection. If a request hits a worker with an open transaction, it gets the correct data. If it hits a different worker, it might not. This also explains why tokens seem valid sometimes and invalid at other times.

With PHP-FPM, this wouldn't be an issue because each request starts fresh. But with Octane, things stay in memory, similar to how Laravel queues work. This could lead to issues if transactions aren't properly committed or rolled back.

[indigoram89]

@totop275 It sounds very plausible.