More versatile error handling in server.TCPConnection

NEW
Unassigned

Status

enhancement
P5
normal
2 years ago
2 years ago

People

(Reporter: ato, Unassigned)

Tracking

Version 3
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

When server.TCPConnection#onPacket receives a new message and it
is not an array we use error.report to log it to stdout.  We could
possibly construct an error response and send that back in this
case.

I don’t think there is anything we can do if sendResponse or sendError
fails, however.
The code Andreas is referring to here can be found at:
https://dxr.mozilla.org/mozilla-central/rev/c2248f85346939d3e0b01f57276c440ccb2d16a1/testing/marionette/server.js#481-486

Andreas, which kind of error class should be used in this case? I would assume `UnknownError`.

Would you mind to mentor this bug?
Flags: needinfo?(ato)
I had a another look into this and I can’t find a good way to know
how to construct an error response when Array.isArray(data) fails.
The response packet is meant to be a four-element array such as
[<type>, <id>, <error>, <data>] but if we fail to unmarshal the
command request we won’t know what command ID to respond to.

Do you have any great ideas?
Flags: needinfo?(ato)
Priority: -- → P5
Oh, indeed. This is really sad. But maybe we could at least use logging in `error.report()`, and get this out as an error, or at least warning?
(In reply to Henrik Skupin (:whimboo) from comment #3)

> Oh, indeed. This is really sad.

I guess we could potentially introduce a message ID -1 meaning
something catastrophic went wrong.  That involves building support
for it into clients as well.

> But maybe we could at least use logging in `error.report()`, and
> get this out as an error, or at least warning?

I believe that already happens.
You need to log in before you can comment on or make changes to this bug.