The Neo4j server reports some error conditions using HTTP status messages such as 404 Not Found or 401 Unauthorized. Almost always, the HTTP response is either empty (Content-Length: 0) or doesn’t really provide any additional information beyond what the status message says.
If additional information is provided, it should in principle be passed on to the user in order to aid debugging. However, the message body of Neo4j responses is typically in text/html or application/json format. Neither is meant for direct human consumption. Simply dumping these in full as an exception with die() probably isn’t very useful.
That’s why Neo4j::Driver currently ignores any response content that isn’t in text/plain format when faced with network errors.
When a JSON response conforms to the usual Neo4j format, it should be easy to parse a readable error string out of it. For example, a 404 response after an org.neo4j.storageengine.migration.UpgradeNotAllowedException has occurred in the Neo4j server looks like this:
{"results":[],"errors":[{"code":"Neo.TransientError.Database.DatabaseUnavailable","message":"Requested database is not available. Requested database name: 'graph.db'."}]}
Neo4j::Driver should pass on both code and message to the user.
In theory, for HTML responses, or for unparseable JSON responses, the first X bytes of an error response could be passed on to die(). With any luck, a clue that aids debugging will be in there. Even if not, it should at least give users a hint that there is something more that’s been cut off.
[see https://github.com/johannessen/neo4j-driver-perl/issues/6#issuecomment-612266437 for context]
The Neo4j server reports some error conditions using HTTP status messages such as
404 Not Foundor401 Unauthorized. Almost always, the HTTP response is either empty (Content-Length: 0) or doesn’t really provide any additional information beyond what the status message says.If additional information is provided, it should in principle be passed on to the user in order to aid debugging. However, the message body of Neo4j responses is typically in
text/htmlorapplication/jsonformat. Neither is meant for direct human consumption. Simply dumping these in full as an exception withdie()probably isn’t very useful.That’s why Neo4j::Driver currently ignores any response content that isn’t in
text/plainformat when faced with network errors.When a JSON response conforms to the usual Neo4j format, it should be easy to parse a readable error string out of it. For example, a
404response after anorg.neo4j.storageengine.migration.UpgradeNotAllowedExceptionhas occurred in the Neo4j server looks like this:Neo4j::Driver should pass on both code and message to the user.
In theory, for HTML responses, or for unparseable JSON responses, the first X bytes of an error response could be passed on to
die(). With any luck, a clue that aids debugging will be in there. Even if not, it should at least give users a hint that there is something more that’s been cut off.