I managed to fix it. The job changed some stuff in the dependency injection container, which was never rolled back.. So I added a call to reset the DIC on every run :D

Thanks for all your help!

It never hits the exception. But I think there might be a weird bug in the job itself. If I just tell the job to return instantly instead of actually running the code, it works..!

There is yes. It is the second job added to the queue. The first one runs as expected..

---TRANSACTION 4377655, ACTIVE 40 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1128, 1 row lock(s)
MySQL thread id 26, OS thread handle 139871028414208, query id 2093 172.20.0.5 foo Updating
UPDATE jobs SET reserved_at = '1726473640' WHERE id = '158'

It seems that it runs the first job as expected. The queue is now empty. I then add a new job, and this locks it up..

| 26 | foo | 172.20.0.5:49924 | foo | Query   |   25 | Updating                 | UPDATE jobs SET reserved_at = '1726473536' WHERE id = '158' |    0.000 |

Thanks for the input!

Yeah it kinda feels that way. It sounds like you are understanding correctly.

I honestly just dont understand why the commit isn't releasing it. I have AUTOCOMMIT on and I also run ->commit() on pdo (dba is just a wrapper around pdo)

    public function transaction(Closure $callback)
    {
        $this->dba->beginTransaction();
        try {
            $result = $callback();

            if ($this->dba->inTransaction()) {
                $this->dba->commit();

            }

            return $result;
        } catch (Exception) {
            $this->dba->rollBack();
            return null;
        }

    }

As far as I can tell Laravel use 'FOR UPDATE` as well, and does not lock up..

I am running MariaDB version 10.3.31