MakeTypedEncoder breaks when using re.SetError

[dignifiedquire]

If I use MakeTypedEncoder, with a concrete type, say *Foo then the error case is not handled correctly anymore, as SetError calls re.Emit but not with type *Foo but rather *cmdkit.Error.

This results in a panic of unexpected type: *cmdkit.Error

[Stebalien]

Are you using this to encode responses sent over the network? The CLI response emitter should be special-casing errors and shouldn't be passing them to the encoder.

[dignifiedquire]

yeah this is over http

…

On 5. Mar 2018, 21:55 +0100, Steven Allen ***@***.***>, wrote: Are you using this to encode responses sent over the network? The CLI response emitter should be special-casing errors and shouldn't be passing them to the encoder. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Stebalien]

Hm. I wonder why I've never seen this in go-ipfs. But yeah, I see the bug.

[Stebalien]

Should be fixed with #112.

[Stebalien]

So, this isn't fixed. We considered simply removing errors from the main stream but didn't because we consider this a part of our "API".

I really don't see a sane fix.

[Stebalien]

@whyrusleeping this can be reproduced with a simple:

curl -F @data="asdf" 'http://localhost:5001/api/v0/object/patch/append-data/Qm?encoding=text'

(and watch how IPFS panics)

[Stebalien]

So, I implemented what I consider to be an "acceptable" fix: #128.