NSManagedHuman / google-api-python-client

Automatically exported from code.google.com/p/google-api-python-client
Other
0 stars 0 forks source link

RuntimeError: maximum recursion depth exceeded #314

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I get this exception with offline acces using StorageByKeyName.

What steps will reproduce the problem?
1. Make a cron job using StorageByKeyName
2. Log in with @decorator.oauth_required
3. Wait

What is the expected output? What do you see instead?
Nothing.
http://www.fpaste.org/53814/36830313/

What version of the product are you using? On what operating system?
1.2 on Appengine

Please provide any additional information below.

Original issue reported on code.google.com by pepijndevos on 13 Nov 2013 at 6:59

GoogleCodeExporter commented 8 years ago
I looked into this a bit more, and it seems to stem from another issue where a 
lot of warnings about positional arguments would be raised when using 
oauth2client.

It appears that this issue is caused by such a warning in the logging code, 
leading to another warning being logged, again triggering the positional 
wrapper warning.

A workaround is to set the positional wrapper to IGNORE.

Original comment by pepijndevos on 25 Nov 2013 at 9:51

GoogleCodeExporter commented 8 years ago
I have a new theory, but no fix yet.

Previous workaround did not actually work. This issue appears about once a week 
at night and lasts for several hours and then goes away again.

After removing all the logging and the decorator, the stacktrace is reduced to 
JUST invocations of request_orig at line 490 in client.py

This suggests that the request is double-wrapped or something. But it's not 
something structural, as it works most of the time.

I thought that maybe it was a bug in refreshing the token, but I have seen some 
successful refreshes being logged.

It's also very hard to debug, because I sleep when it happens.

Original comment by pep...@bvdot.tk on 11 Dec 2013 at 11:47

GoogleCodeExporter commented 8 years ago
I think I found the problem. I had code like this.

http = httplib2.Http(memcache)

def oauth_stuff(cred):
    auth_http = cred.authorize(http)
    do_oauth_stuff()

I found out the hard way that authorize returns the same http object with a new 
request function.
So every time this function gets called, it adds a layer of authorization.

This also explains why it takes so long to manifest. It takes 
sys.getrecursionlimit() calls to any method using oauth to trigger the bug.
But not much more, as load increases in the morning, new instances get started 
and the bug goes away.

A fix is attached that prevents double wrapping.

Original comment by pep...@bvdot.tk on 11 Dec 2013 at 12:52

Attachments: