Brad Bell

@hiasl you can see the logic for the default postgres backup command Craft uses here: https://github.com/craftcms/cms/blob/develop/src/db/pgsql/Schema.php#L117-L160

Even better, you can completely override the default backup/restore commands for your specific needs and the `craft db/backup` and `craft db/restore` commands will respect them via: https://craftcms.com/docs/4.x/config/config-settings.html#backupcommand https://craftcms.com/docs/4.x/config/config-settings.html#restorecommand

> Let me know what you think but maybe a craft db/empty command or an addition to the restore command would still be a good idea since it's a rather...

Thanks for sharing!

> The important part: The problem goes away when we delete the cookie PHPSESSID. Unless you've changed https://craftcms.com/docs/4.x/config/config-settings.html#phpsessionname, then that's not a Craft-managed PHP session cookie - some other code...

@DavidKabelitz do you have multiple queue runners processing the queue or just one? Is this in a load-balanced environment?

@DavidKabelitz How are the queue runner(s) set up? Using Craft's default web-based queue runner, so each pod ends up being a queue runner? Or is there a dedicated pod just...

It almost sounds like it's bumping into a Redis connection time limit, then Redis kills the connection and you get the "Error: Failed to read from socket." error. Not that...

Hrm... are there any sort of Redis logs exposed to you that might hold some clues when it happens?

Might help to remove some variables from the equation to try and narrow down the issue? i.e. remove Azure Kubernetes Cluster and get the sight running on a straight VM...