Repository navigation
Conversation
sstrigler
force-pushed
the
improve_error_reporting
branch
from
November 8, 2026 09:20
79ab894 to
6fc0d18
Compare
sstrigler
force-pushed
the
improve_error_reporting
branch
from
November 8, 2026 10:56
6fc0d18 to
f771359
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a crash in an iq handler occurs we produce an ID for this error to help trace what went wrong.
This PR also restores the old behavior when a db_failure occurs in mod_blocking, which was changed in 7524cf4.
Rather than writing a stack trace in the log we now produce an error message with the error reason reported from the backend.
The idea here is to be able to write code that focuses more on the happy path rather than handling the same error everywhere over and over inflating the code base with repetitive code.
The commit above was meant as a starting point for improving error handling in general in favor of more readable and more concise code.
Ultimately some changes to
ejabberd_sqlwould have to be done so that we're able to tell whether an error was due to an actual software failure like a broken, faulty sql query or a system failure like high latency, overload, connection issues etc.Those would need to be treated differently since the first one needs to be handled by a developer and here we'd need stacktraces in the logs while the other class of errors needs to be handled by a server admin.
But that's something I'd need help with.