The idea:
Allow us to extend the DetectsLostConnection array of strings with an array of strings in config/database.php
The background
I'm in a situation using Google Cloud Platform with managed PostgreSQL service and when the database restarts randomly, the queue workers hang. Supervisor has no control over them. I have to manually sudo kill the queue process.
That led me to the QueueWorker being able to handle this by detecting if the database connection is lost based on the predefined strings in DetectsLostConnections. If you see that link you can see the blame history for all the additions that are very specific to whichever database and service you are using. But if the specific message for your system doesn't match, it won't detect a lost connection.
For example, in the list there is a:
SQLSTATE[HY000]: General error: 7 SSL SYSCALL error: EOF detected
line in the file, but on my stack the error is reported as
SQLSTATE[08006] [7] SSL SYSCALL error: EOF detected
The text is formatted differently so it won't match. If it was matching only SSL SYSCALL error: EOF detected, then it would detect it.
I also get:
SQLSTATE[08006] [7] SSL SYSCALL error: SuccessSQLSTATE[08006] [7] FATAL: the database system is in recovery mode SQLSTATE[08006] [7] could not connect to server: Connection refused Is the server running on host "IP_ADDRESS_REDACTED" and accepting TCP/IP connections on port 5432?
The last one used to be picked up by matching against "Connection refused", until this PR made the line more specific and now it doesn't.
It seems unscalable to keep having to update the framework for every permutation of message produced by stacks where we have no control over how the messages are presented. I see some of the PRs adding extra strings are for managed databases.
There have been 9 new strings added to the framework in the last 12 months
The idea: Allow us to extend the DetectsLostConnection array of strings with an array of strings in
config/database.phpThe background I'm in a situation using Google Cloud Platform with managed PostgreSQL service and when the database restarts randomly, the queue workers hang. Supervisor has no control over them. I have to manually
sudo killthe queue process.That led me to the QueueWorker being able to handle this by detecting if the database connection is lost based on the predefined strings in DetectsLostConnections. If you see that link you can see the blame history for all the additions that are very specific to whichever database and service you are using. But if the specific message for your system doesn't match, it won't detect a lost connection.
For example, in the list there is a:
SQLSTATE[HY000]: General error: 7 SSL SYSCALL error: EOF detectedline in the file, but on my stack the error is reported asSQLSTATE[08006] [7] SSL SYSCALL error: EOF detectedThe text is formatted differently so it won't match. If it was matching only
SSL SYSCALL error: EOF detected, then it would detect it.I also get:
SQLSTATE[08006] [7] SSL SYSCALL error: SuccessSQLSTATE[08006] [7] FATAL: the database system is in recovery modeSQLSTATE[08006] [7] could not connect to server: Connection refused Is the server running on host "IP_ADDRESS_REDACTED" and accepting TCP/IP connections on port 5432?The last one used to be picked up by matching against "Connection refused", until this PR made the line more specific and now it doesn't.
It seems unscalable to keep having to update the framework for every permutation of message produced by stacks where we have no control over how the messages are presented. I see some of the PRs adding extra strings are for managed databases.
There have been 9 new strings added to the framework in the last 12 months