Opened at 2022-10-01T23:29:33Z
Last modified at 2022-10-02T23:53:29Z
#3929 new defect
Error reading directory: 'coroutine' object has no attribute 'addCallback'
Reported by: | meejah | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | code-frontend-web | Version: | unknown |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
On a very recent revision (d2dd21142) I see an error why opening a read-only directory cap (in the WebUI):
Error reading directory: 'coroutine' object has no attribute 'addCallback'
Change History (5)
comment:1 Changed at 2022-10-01T23:43:15Z by meejah
comment:2 Changed at 2022-10-02T00:29:57Z by meejah
This appears to be an interaction with very-new (unreleased) ZKAPAuthorizer plugin
comment:3 Changed at 2022-10-02T12:33:55Z by exarkun
This sounds like it is probably the same as https://github.com/PrivateStorageio/ZKAPAuthorizer/issues/433
comment:4 Changed at 2022-10-02T22:55:17Z by meejah
Yeah, probably the same thing.
However, tahoe should probably do something better as far as error-reporting here I think. I couldn't see anywhere the actual stack trace ends up, for example.
Also we should declare whether coroutines are supported or not for these sorts of plugins. Obviously, the easy answer is to say "no" but it _should_ just be a matter of consistently calling maybeDeferred on everything, right? (If we use a new-enough Twisted to get the new behavior where it calls ensureDeferred).
comment:5 Changed at 2022-10-02T23:53:29Z by exarkun
However, tahoe should probably do something better as far as error-reporting here I think. I couldn't see anywhere the actual stack trace ends up, for example.
I think they might have gone to the Foolscap log. I've started a branch trying to replace the Foolscap log with twisted.python.log. Superficially most things still seem to work (that is, most of the test suite passes) but a few tests fail in a mysterious way I haven't managed to understand yet.
I _hope_ that switching from the Foolscap log to twisted.python.log means unhandled exceptions like this will be more visible.
Trying to bisect or so, even 1.17.1 exhibits this behavior -- so I think it's actually from an updated dependency??