[Flight] Fix hasReadable flag in Node.js clients' debug channel#35039
Merged
unstubbable merged 1 commit intofacebook:mainfrom Nov 4, 2025
Merged
Conversation
For Edge Flight servers, that use Web Streams, we're defining the
`debugChannel` option as:
```
debugChannel?: {readable?: ReadableStream, writable?: WritableStream, ...}
```
Whereas for Node.js Flight servers, that use Node.js Streams, we're
defining it as:
```
debugChannel?: Readable | Writable | Duplex | WebSocket
```
For the Edge Flight clients, there is currently only one direction of
the debug channel supported, so we define the option as:
```
debugChannel?: {readable?: ReadableStream, ...}
```
Consequently, for the Node.js Flight clients, we define the option as:
```
debugChannel?: Readable
```
The presence of a readable debug channel is passed to the Flight client
internally via the `hasReadable` flag on the internal `debugChannel`
option. For the Node.js clients, that flag was accidentally derived from
the public option `debugChannel.readable`, which is conceptually
incorrect, because `debugChannel` is a `Readable` stream, not an options
object with a `readable` property. However, a `Readable` also has a
`readable` property, which is a boolean that indicates whether the
stream is in a readable state. This meant that the `hasReadable` flag
was incidentally still set correctly. Regardless, this was confusing and
unintentional, so we're now fixing it to always set `hasReadable` to
`true` when a `debugChannel` is provided to the Node.js clients. We'll
revisit this in case we ever add support for writable debug channels in
Node.js (and Edge) clients.
|
Comparing: edd05f1...1340a57 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
sebmarkbage
approved these changes
Nov 4, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For Edge Flight servers, that use Web Streams, we're defining the
debugChanneloption as:Whereas for Node.js Flight servers, that use Node.js Streams, we're defining it as:
For the Edge Flight clients, there is currently only one direction of the debug channel supported, so we define the option as:
Consequently, for the Node.js Flight clients, we define the option as:
The presence of a readable debug channel is passed to the Flight client internally via the
hasReadableflag on the internaldebugChanneloption. For the Node.js clients, that flag was accidentally derived from the public optiondebugChannel.readable, which is conceptually incorrect, becausedebugChannelis aReadablestream, not an optionsobject with a
readableproperty. However, aReadablealso has areadableproperty, which is a boolean that indicates whether the stream is in a readable state. This meant that thehasReadableflag was incidentally still set correctly. Regardless, this was confusing and unintentional, so we're now fixing it to always sethasReadabletotruewhen adebugChannelis provided to the Node.js clients. We'll revisit this in case we ever add support for writable debug channels in Node.js (and Edge) clients.