Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeError: 'NoneType' object is not subscriptable #59

Open
guyco-redis opened this issue Oct 27, 2022 · 3 comments
Open

TypeError: 'NoneType' object is not subscriptable #59

guyco-redis opened this issue Oct 27, 2022 · 3 comments

Comments

@guyco-redis
Copy link

Got the following traceback:

  File "/opt/redislabs/lib/python3.9/site-packages/jsonrpclib/jsonrpc.py", line 778, in __call__
    return self.__send(self.__name, kwargs)
  File "/opt/redislabs/lib/python3.9/site-packages/jsonrpclib/jsonrpc.py", line 652, in _request
    return response["result"]
TypeError: 'NoneType' object is not subscriptable

from what I could see ServerProxy._request performs self._run_request(request), which can return None, in which case check_for_errors returns the same None, and that is accessed.

@tcalmant
Copy link
Owner

Hi,

Would you have a use case that generates that situation, in order to prepare a unit test?

According to the specification, all requests except notifications must return a response object.

As a result, it would be more helpful to raise a TypeError exception with a message indicating that the server returned an invalid response
.
What is your opinion on the matter?

Note: in the master branch of this project, the issue would be on line 632

@tcalmant
Copy link
Owner

I have made an issue59 branch with an explicit error. Could you try if it fits your needs?

@guyco-redis
Copy link
Author

Hi @tcalmant , unfortunately I don't have a use case that generates this bug, I only saw this traceback through production logs.
Looking through _run_request which calls self.__transport.request, this might result by an error like errno.ECONNRESET, errno.ECONNABORTED or errno.EPIPE (which won't raise an exception)?

I think raising an informative TypeError should be good in this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants