Handling parity errors with a ReadableStream

[reillyeon]

When parity error detection is enabled it is unclear how this should be communicated to a client using the ReadableStream interface. Unlike the errors that can be encountered in the response body of a fetch() these are not fatal. The options as I see it,

1. Ignore errors.
2. Halt the ReadableStream when an error is detected and require the error to be explicitly cleared to open a new stream that will receive the next byte after the error.
3. Signal errors in-band using a mechanism similar to the PARMRK flag on POSIX systems. The application will need to inspect the input byte by byte to separate errors from the actual data.

[reillyeon]

@reconbot how is this handled in node-serialport?

[reconbot]

We don't do anything special, each os has a default behavior which is pretty similar. 1) ignore it from an high level perspective 2) injectect a parity read error byte ? For windows, and something I don't recall on Linux. In 7 years of support issues it hasn't come up much.

…

On Fri, Sep 28, 2018, 5:45 PM Reilly Grant ***@***.***> wrote: @reconbot <https://github.com/reconbot> how is this handled in node-serialport? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABlbn4lYCek6WAMigUlYNba_z3dtIdLks5ufqaJgaJpZM4XAKpE> .

[reconbot]

If I were to add it to serialport, I'd handle it underneath our node streams layer at the binding layer and which would probably expose it as a configuration settings, for choosing the error character and if possible having it produce a read error. I need to do more research to know what's possible.

Our bindings needs better docs but it looks something like this and I'm working on a next version with lessons learned on this spec serialport/node-serialport#1679 I'm still exploring the api. Since the binding layer is closer to the actual syscalls and doesn't have a concept of a stream, we can use it to build node streams, ReadableStream, async iterator, or whatever interface is de jour.

[domenic]

It looks like the current explainer has settled on (2). This is an interesting point on the design space, and I think it's pretty reasonable. (3) seems most "natural" in some ways but also quite inconvenient for web developers. /cc @ricea as the other Streams editor since this might set an interesting precedent.

I'll also offer

4. Signal errors out of band, e.g. with an ever-growing port.readingErrors property, which the application can optionally consult after each read.

I'm not sure on the details there and it might be bad. E.g., I guess you return zero-byte Uint8Arrays when there's an error? Hmm. Anyway, I think it's worse than (2).

But the real purpose of my comment is to encourage you to add an "Alternatives considered" section to the explainer exploring these different alternatives and their tradeoffs.