Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ext/net): node compatibility issue missing fd in createServer callback socket object #27789

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

muthu90tech
Copy link
Contributor

@muthu90tech muthu90tech commented Jan 23, 2025

This PR will address the node compatibility issue where, the callback socket object in net.createServer is missing a fd in socket._handle

Modified this PR to use internal symbol to expose fd instead of exposing it via lib.deno.d.ts
denoland/deno_core#1061

fixes: #27788

…lback socket object

This PR will address the node compatibility issue where, the callback socket
object in net.createServer is missing a fd in socket._handle

fixes: denoland#27788
@@ -138,6 +138,8 @@ declare namespace Deno {

readonly readable: ReadableStream<Uint8Array>;
readonly writable: WritableStream<Uint8Array>;

readonly fd: number;
Copy link
Member

@kt3k kt3k Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is desirable addition to Deno API because no other resources expose file descriptor.

We generally use rid as a substitute to fd in node compat layer. Doesn't it work to assign conn.rid to handle.fd for TCP handle for your use case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi thanks for the review, since the rid is a pointer to the internal tcpstream resource and is an abstraction, we would like to print the actual file descriptor the connection is using for observability purposes. Thank you

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ry @bartlomieju What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine exposing fd in the Node compat API, but we shouldn't do it in the Deno APIs. IMO this should be handled the same way we're passing resource IDs between Deno APIs and Node APIs (via a private symbol)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bartlomieju Got it, I pushed another commit to use internal symbols to expose fd, thank you
denoland/deno_core#1061

muthu90tech added a commit to muthu90tech/deno_core that referenced this pull request Jan 25, 2025
please take a look at this PR: denoland/deno#27789
Use an internal symbol to expose fd created after establishing a socket connection
in the server side.
The node apis expose fd, this ensures the deno node apis are compatible.
muthu90tech added a commit to muthu90tech/deno_core that referenced this pull request Jan 25, 2025
…ol in deno_core

Please take a look at PR: denoland/deno#27789
This change will help to expose fd to server when a socket connection is
established.
@bartlomieju
Copy link
Member

@muthu90tech I merged your deno_core PR. It will be a few days before it gets released, so for now you can use Cargo patch functionality to point to a latest commit on main branch in deno_core instead of a fixed version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deno node compatibility issue where the callback object in net.createServer is missing fd
3 participants