Error reading directory: 'coroutine' object has no attribute 'addCallback' #3929

New Issue

meejah · 2022-10-01T23:29:33Z

meejah commented

2022-10-01 23:29:33 +00:00

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'

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'`

meejah added the

labels 2022-10-01 23:29:33 +00:00

meejah added this to the undecided milestone 2022-10-01 23:29:33 +00:00

meejah commented

2022-10-01 23:43:15 +00:00

Trying to bisect or so, even 1.17.1 exhibits this behavior -- so I think it's actually from an updated dependency??

meejah commented

2022-10-02 00:29:57 +00:00

This appears to be an interaction with very-new (unreleased) ZKAPAuthorizer plugin

exarkun commented

2022-10-02 12:33:55 +00:00

This sounds like it is probably the same as https://github.com/PrivateStorageio/ZKAPAuthorizer/issues/433

This sounds like it is probably the same as <https://github.com/PrivateStorageio/ZKAPAuthorizer/issues/433>

meejah commented

2022-10-02 22:55:17 +00:00

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).

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`).

exarkun commented

2022-10-02 23:53:29 +00:00

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.

> 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.

Sign in to join this conversation.