http2: add session tracking and graceful server shutdown of http2 server #57586

pandeykushagra51 · 2025-03-21T22:32:27Z

This change adds proper tracking of HTTP/2 server sessions to ensure they are gracefully closed when the server is shut down. It implements:

A new kSessions symbol for tracking active sessions
Adding/removing sessions from a SafeSet in the server
A closeAllSessions helper function to properly close all active sessions
Updates to Http2Server and Http2SecureServer close methods

Breaking Change: any client trying to create new requests on existing connections will not be able to do so once server close is initiated

Fixes: #57611
Refs: https://datatracker.ietf.org/doc/html/rfc7540#section-9.1
Refs: https://nodejs.org/api/http.html#serverclosecallback

More Details:

Purpose

This PR implements proper tracking and graceful shutdown of HTTP/2 sessions when a server is closed. It addresses the gap between the documented behavior of server.close() and its actual implementation for HTTP/2 servers. Also if server have fired close, we should allow it to close as early as possible to free up system resources quickly. This change ensure that once server wants to close, goaway frame will be sent to every open session(connection) so that client get to know that server started shutdown process and client should not send any new request on existing connection.

Current Issues

Currently, HTTP/2 servers are at the mercy of clients to close connections.
There is no mechanism to notify clients that the server wants to shut down.
Misbehaving/Non-compliant clients can keep connections open indefinitely, preventing proper server shutdown.
Clients can continue to initiate new requests on existing connections even when the server is trying to close.
Start of server shutdown can starve indefinitely, leading to processes that cannot terminate cleanly and causing resource leaks.

Implementation Details

Added a kSessions symbol and SafeSet to track active HTTP/2 sessions.
Implemented session registration when sessions are created.
Created a closeAllSessions helper function to initiate graceful shutdown of all tracked sessions
Updated Http2Server and Http2SecureServer close methods to use this functionality

Behavior Clarification

According to the Node.js documentation for server.close():

server.close stops the server from accepting new connections and closes all connections connected to this server which are not sending a request or waiting for a response.

This PR ensures that HTTP/2 servers follow this behavior by:
Closing existing HTTP/2 sessions gracefully, which means:

When session.close() is called, a GOAWAY frame is sent to notify clients that the server wants to close the session
No new streams (requests) can be initiated on existing connections
Existing streams can continue writing/reading data until completion
In-flight requests will be allowed to complete
Sessions will be terminated after all active streams complete

This implementation aligns with the HTTP/2 protocol specification for connection management as described in RFC 7540 Section 9.1.

API Impact

This is technically a breaking change, as clients attempting to create new requests on existing HTTP/2 connections will be unable to do so once server.close() is called. However, this behavior now correctly matches the documented behavior for HTTP servers.

Testing

This PR includes tests to verify that HTTP/2 sessions are properly tracked and gracefully shut down when the server is closed.

Newly added test files:

test-http2-request-after-server-close.js: Verifies that after server.close() is called, clients cannot initiate new requests while existing requests are allowed to complete. Confirms the server properly terminates once all connections are closed.
test-http2-server-close-client-behavior.js: Validates that idle connections are immediately closed when server.close() is called, while connections with active streams continue processing until completion. Ensures the server terminates after all connections are properly closed.

Modified test files:

test-http2-compat-serverresponse-statusmessage-property-set.js: After server close behavior is updated, this test started to fail. The failure happened because the request from client is under pendingAck state so the session is not yet initiated, as server close is fired during this time and hence client didn't received response which leads to test failure. Now the test is updated to fire server close once the request is complete. As this unit test, test that client should receive http2 status message response, so it is good to close the server only after the request/response cycle is completed. This line tells that pending stream will be cancelled once session close is emitted.
test-http2-compat-serverresponse-statusmessage-property.js: Same as above.
test-http2-capture-rejection.js: Server close should be fired after server have sent push promise frame.

nodejs-github-bot · 2025-03-21T22:32:32Z

Review requested:

@nodejs/http2
@nodejs/net

pandeykushagra51 · 2025-03-22T20:34:34Z

This strategy is adopted in other server like Springboot (Tomcat) and golang as well for gracefull server close

pandeykushagra51 · 2025-03-22T20:39:10Z

Please review the changes, I will be very happy to work on any suggestion and any scope of improvement.

mcollina

lgtm

codecov · 2025-03-27T17:52:16Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (af75d04) to head (90acf08).
Report is 108 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #57586      +/-   ##
==========================================
- Coverage   90.23%   90.21%   -0.02%     
==========================================
  Files         630      630              
  Lines      185055   185547     +492     
  Branches    36221    36392     +171     
==========================================
+ Hits       166984   167397     +413     
+ Misses      11043    11030      -13     
- Partials     7028     7120      +92

Files with missing lines	Coverage Δ
lib/internal/http2/core.js	`95.67% <100.00%> (+0.06%)`	⬆️

... and 80 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

lpinca · 2025-03-27T20:54:32Z

A new kSessions symbol for tracking active sessions

Adding/removing sessions from a SafeSet in the server

A closeAllSessions helper function to properly close all active sessions

Updates to Http2Server and Http2SecureServer close methods

I just took a quick look, but can't all of this be done in userland? What is the advantage of doing this in core and forcing session tracking for everyone?

pandeykushagra51 · 2025-03-28T02:10:55Z

A new kSessions symbol for tracking active sessions

Adding/removing sessions from a SafeSet in the server

A closeAllSessions helper function to properly close all active sessions

Updates to Http2Server and Http2SecureServer close methods

I just took a quick look, but can't all of this be done in userland? What is the advantage of doing this in core and forcing session tracking for everyone?

No doubt that this can be done on user side as well but this feature is surely going to provide convenience to users.
In my opinion, once user call server.close(), it should be responsibility of nodejs to close the server and handle all internal things. It will be a bit unconventional to ask user to first close the server and then manually intercept all session and close session from there. The user should be free once they call server.close() and should rely on server that it can handle everything else.
Regarding tracking for everyone, we follow this approach in net and http module as well where we store data related to connection for each net server.
here is reference:

node/lib/net.js

Line 1800 in 0a91e98

this._connections = 0;

node/lib/_http_server.js

Line 519 in 0a91e98

this[kConnections] ||= new ConnectionsList();

Also this strategy is widely adopted in other server like go and springboot (tomacat).

pandeykushagra51 · 2025-03-28T02:15:27Z

It will be really helpful if someone can tell what could be possible reason for test failure? I have tried running them locally (on mac-os) and all test test passed as expected.

pandeykushagra51 · 2025-03-28T02:20:04Z

A new kSessions symbol for tracking active sessions

Adding/removing sessions from a SafeSet in the server

A closeAllSessions helper function to properly close all active sessions

Updates to Http2Server and Http2SecureServer close methods

I just took a quick look, but can't all of this be done in userland? What is the advantage of doing this in core and forcing session tracking for everyone?

Also I have seen an issue #55459 which is under triaged state, that can also be done easily once this PR is merged.
As this PR add session tracking, we would only need to iterate the connection list and just destroy the session.

pandeykushagra51 · 2025-03-28T03:16:30Z

update regarding failing test cases:

test-http2-server-close-client-behavior (macOS): The test failed because the server should ideally close once all sessions are terminated. On my local macOS machine, it passes as expected, but it fails on CI—likely due to resource constraints. The failure appears to be caused by a slight delay of around 80ms in the actual server shutdown. This indicates test flakiness rather than an issue with the server itself. To address this, I will update the test to allow some flexibility, ensuring it still passes even if the server takes an additional 200-300ms to close. This accounts for internal processes like the garbage collector, which may introduce slight delays.

test-http2-server-http1-client.js(ubuntu-24.04, ubuntu-24.04-arm): Although these tests passed locally but not sure why failing on CI, will investigate further and keep posted here

lpinca · 2025-03-28T07:24:49Z

In my opinion, once user call server.close(), it should be responsibility of nodejs to close the server and handle all internal things. It will be a bit unconventional to ask user to first close the server and then manually intercept all session and close session from there.

That's not how it works in Node.js. The close method of net.Server and tls.Server does not close active connections by design. It is user responsibility to do that.

The close method of http.Server also worked like this. In version 19.0.0, the behavior was changed to automatically close idle connections, but active connections (those that are sending a request or receiving a response) are kept open. I would be ok to align http2 to this behavior, but is there a way to find idle sessions?

Changing the close method behavior is a breaking change, and for consistency with other servers, it should not be done in my opinion. As written in the previous comment, the desired behavior can easily be achieved in userland (with the exact same code, no core changes are needed).

As for testing, if possible, do not use timers as they make the tests flaky.

pandeykushagra51 · 2025-03-28T08:06:08Z

I would be ok to align http2 to this behavior, but is there a way to find idle sessions?

In my opinion, any session which are not having any open request/stream will be referred as idle session. Please let me know your thoughts on this.

That's not how it works in Node.js. The close method of net.Server and tls.Server does not close active connections by design. It is user responsibility to do that.

Confirming the behavior again, in current changes, active sessions are not closed.

pimterry

Thanks for the contribution @pandeykushagra51!

HTTP servers server.close() nowadays does close idle connections, and personally I'd be happy for HTTP/2 servers to match that behaviour, although as a breaking change. The basic approach seems sensible to me (although note the race condition I've commented on here).

AFAICT it does seem like this PR does actually match that close-idle behaviour already (it calls session.close(), which apparently allows all pending streams to complete before closing the session) so this isn't unreasonable. That said, we do definitely need a test which calls server.close() while a request is still pending and then checks it completes OK and closes afterwards.

The current tests here need some substantial changes though I think. Most importantly: we shouldn't be using setTimeout and timing checks anywhere in here. That will make these tests very flaky (as shown by CI here) and much slower than they need to be. There's also quite complicated, it seems like they're testing a few different things and it's not exactly clear what's going on.

We should avoid depending on specific timing (by instead waiting for events, and then triggering the next step after each previous event, etc), and these tests should be simplified and/or broken into separate tests too I think. With those changes, that will probably fix the CI test failures here. You might find it useful to take a look at the HTTP & net server close tests for some examples.

lib/internal/http2/core.js

pimterry · 2025-03-28T13:23:27Z

lib/internal/http2/core.js

@@ -3205,6 +3227,7 @@ class Http2SecureServer extends TLSServer {
    if (this[kOptions].allowHTTP1 === true) {
      httpServerPreClose(this);
    }
+    closeAllSessions(this);
    ReflectApply(TLSServer.prototype.close, this, arguments);


Same race condition as below. We might also need to do this before httpServerPreClose as well (needs investigation) and we should check this works for any HTTP/1 connections here too.

Hey @pimterry could you please review again

pandeykushagra51 · 2025-03-28T15:11:40Z

Thanks for the contribution @pandeykushagra51!

HTTP servers server.close() nowadays does close idle connections, and personally I'd be happy for HTTP/2 servers to match that behaviour, although as a breaking change. The basic approach seems sensible to me (although note the race condition I've commented on here).

AFAICT it does seem like this PR does actually match that close-idle behaviour already (it calls session.close(), which apparently allows all pending streams to complete before closing the session) so this isn't unreasonable. That said, we do definitely need a test which calls server.close() while a request is still pending and then checks it completes OK and closes afterwards.

The current tests here need some substantial changes though I think. Most importantly: we shouldn't be using setTimeout and timing checks anywhere in here. That will make these tests very flaky (as shown by CI here) and much slower than they need to be. There's also quite complicated, it seems like they're testing a few different things and it's not exactly clear what's going on.

We should avoid depending on specific timing (by instead waiting for events, and then triggering the next step after each previous event, etc), and these tests should be simplified and/or broken into separate tests too I think. With those changes, that will probably fix the CI test failures here. You might find it useful to take a look at the HTTP & net server close tests for some examples.

thanks a lot @pimterry for your input, I will b working on these and will update the PR as requested

lpinca · 2025-03-28T17:32:29Z

In my opinion, any session which are not having any open request/stream will be referred as idle session. Please let me know your thoughts on this.

It makes sense.

lpinca · 2025-03-28T19:37:16Z

@pandeykushagra51 can you please rebase this against main, apply the new changes and force push here instead? In this way we have all the context/comments in the same place.

pandeykushagra51 · 2025-03-28T20:05:31Z

@pandeykushagra51 can you please rebase this against main, apply the new changes and force push here instead? In this way we have all the context/comments in the same place.

done the changes, thanks for informing 🙂

This change adds proper tracking of HTTP / 2 server sessions to ensure they are gracefully closed when the server is shut down.It implements: - A new kSessions symbol for tracking active sessions - Adding/removing sessions from a SafeSet in the server - A closeAllSessions helper function to close active sessions - Updates to Http2Server and Http2SecureServer close methods Breaking Change: any client trying to create new requests on existing connections will not be able to do so once server close is initiated Refs: https://datatracker.ietf.org/doc/html/rfc7540\#section-9.1 Refs: https://nodejs.org/api/http.html\#serverclosecallback

1. Fix server shutdown race condition - Stop listening for new connections before closing existing ones - Ensure server.close() properly completes in all scenarios 2. Improve HTTP/2 tests - Replace setTimeout with event-based flow control - Simplify test logic for better readability - Add clear state tracking for event ordering - Improve assertions to verify correct shutdown sequence This eliminates a race condition where new sessions could connect between the time existing sessions are closed and the server stops listening, potentially preventing the server from fully shutting down.

…d strengthen test

lpinca · 2025-04-07T09:19:23Z

test/parallel/test-http2-graceful-close.js

+  // When the request completes
+  req.on('end', common.mustCall());
+


Suggested change

// When the request completes

req.on('end', common.mustCall());

lpinca · 2025-04-07T09:20:52Z

test/parallel/test-http2-graceful-close.js

+    // Should receive all data
+    assert.strictEqual(receivedData, 64 * 1024 * 16);


Suggested change

// Should receive all data

assert.strictEqual(receivedData, 64 * 1024 * 16);

// Should receive all data

assert.strictEqual(req.readableEnded, true);

assert.strictEqual(receivedData, 64 * 1024 * 16);

assert.strictEqual(req.writableFinished, true);

lpinca · 2025-04-07T09:22:03Z

test/parallel/test-http2-graceful-close.js

+  });
+
+  stream.on('close', common.mustCall(() => {
+    assert.strictEqual(stream.writableFinished, true);


Suggested change

assert.strictEqual(stream.writableFinished, true);

assert.strictEqual(stream.readableFinished, true);

assert.strictEqual(stream.writableFinished, true);

just found from nodejs docs that readable do not have readableFinished property but have readableEnded so replaced with that

Yes, it was a typo.

lpinca · 2025-04-07T09:35:20Z

test/parallel/test-http2-graceful-close.js

+
+  // Initiate the server close before client data is sent, this will
+  // test if the server properly waits for the stream to finish
+  server.close(common.mustCall());


Suggested change

server.close(common.mustCall());

server.close();

Feel free to keep the callback, it is not wrong, but in my opinion it is not useful for the purpose of the test, it is only additional overhead.

make sense, done the changes

lpinca · 2025-04-07T09:42:06Z

test/parallel/test-http2-server-close-idle-connection.js

+    stream.on('close', common.mustCall(() => {
+      assert.strictEqual(stream.writableFinished, true);
+    }));


Suggested change

stream.on('close', common.mustCall(() => {

assert.strictEqual(stream.writableFinished, true);

}));

Feel free to keep it, but I don't think it is useful as the server is closed after the request ends (the 'end' event is emitted on the client).

I have a but different opinion, I would like to keep it

we should ensure that server side stream have closed before server close

The server does not close if there are open streams, no?

IMO if there are open stream we can’t call it graceful closure

Yes, that's the point, if the stream is not closed via server.close(), the process does not exit. If the process exits then it means that the stream and the server were closed. stream.writableFinished is already tested on the client side. Anyway, it does not matter.

Do you think we should still remove that?

lpinca · 2025-04-07T09:45:08Z

test/parallel/test-http2-server-close-idle-connection.js

+  // Make an initial request
+  const req = client.request({ ':path': '/' });
+
+  req.on('response', common.mustCall());


Suggested change

req.on('response', common.mustCall());

I don't think this is useful for the purpose of the test.

done the changes

lpinca · 2025-04-07T09:46:14Z

test/parallel/test-http2-server-close-idle-connection.js

+    assert.strictEqual(data, 'hello');
+    // Close the server as client is idle now
+    setImmediate(() => {
+      server.close(common.mustCall());


Suggested change

server.close(common.mustCall());

server.close();

nodejs-github-bot · 2025-04-08T14:50:12Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66134/

pandeykushagra51 · 2025-04-08T17:48:06Z

@mcollina @ronag this PR is having two approval and no any pending requested changes.
Could you please let me know what things need to be followed from my end to get this PR merged.
Also is there anything to do with failing checks?

nodejs-github-bot · 2025-04-08T17:51:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66140/

pimterry · 2025-04-08T17:56:06Z

@pandeykushagra51 We should wait for @lpinca to re-review, but once that's sorted then there's nothing else required from your side, we'll do the steps to wrap it up and merge it.

The CI tests can be a little flaky, but I don't think there's anything related to this change that's failing there, so nothing to worry about. We'll re-run those as required and sort that out, and then this PR will be landed.

lpinca · 2025-04-08T18:10:54Z

My comments/requests have been addressed. I do not approve because I think it does not belong to core. The argument for consistency with httpServer.close() is valid. I'm neutral.

nodejs-github-bot · 2025-04-08T19:11:18Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66144/

nodejs-github-bot · 2025-04-09T09:06:23Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66160/

mcollina

lgtm with a nit

mcollina · 2025-04-09T09:09:33Z

lib/internal/http2/core.js

+  if (sessions.size > 0) {
+    sessions.forEach((session) => {
+      session.close();
+    });


Can you please use a for...of loop?

nodejs-github-bot · 2025-04-09T09:22:30Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66162/

pandeykushagra51 · 2025-04-09T20:25:22Z

hey @lpinca @pimterry @mcollina I found an issue with graceful http2 session closure and implemented fix at #57808 . I will be very happy to optimise and improve it further in case of any scope and will be eagerly waiting for your feedback,

Sorry for putting it here but I think this is a potential bug (may be security related) so thought of informing here to fast forward process.

Thankyou

nodejs-github-bot · 2025-04-11T15:46:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66200/

nodejs-github-bot · 2025-04-11T20:00:04Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66207/

nodejs-github-bot · 2025-04-12T12:30:59Z

CI: https://ci.nodejs.org/job/node-test-pull-request/66213/

nodejs-github-bot added http2 Issues or PRs related to the http2 subsystem. needs-ci PRs that need a full CI run. labels Mar 21, 2025

pandeykushagra51 changed the title ~~http2: add session tracking and graceful shutdown of http2 server~~ http2: add session tracking and graceful server shutdown of http2 server Mar 23, 2025

mcollina requested review from atlowChemi and jasnell March 27, 2025 16:41

mcollina assigned ronag Mar 27, 2025

mcollina approved these changes Mar 27, 2025

View reviewed changes

mcollina requested a review from pimterry March 27, 2025 16:42

mcollina added the semver-major PRs that contain breaking changes and should be released in the next major version. label Mar 27, 2025

pimterry requested changes Mar 28, 2025

View reviewed changes

pandeykushagra51 mentioned this pull request Mar 28, 2025

http2: add session tracking and graceful server close #57668

Closed

pandeykushagra51 requested a review from pimterry March 28, 2025 19:41

pandeykushagra51 force-pushed the http2/fix-server-close branch from f2a480c to da31e96 Compare March 28, 2025 19:53

pandeykushagra51 added 2 commits March 29, 2025 16:23

pandeykushagra51 added 2 commits April 7, 2025 01:22

resolved pr comments on test-http2-graceful-close.js

dd751ae

resolved pr comments on test-http2-server-close-idle-connection.js an…

be55b6d

…d strengthen test

pandeykushagra51 requested review from lpinca and pimterry April 6, 2025 21:03

lpinca reviewed Apr 7, 2025

View reviewed changes

resolved pr comments: done suggested changes from lpinca

8ee2e3e

pandeykushagra51 requested a review from lpinca April 7, 2025 18:20

pimterry approved these changes Apr 8, 2025

View reviewed changes

pimterry added the request-ci Add this label to start a Jenkins CI on a PR. label Apr 8, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 8, 2025

mcollina approved these changes Apr 9, 2025

View reviewed changes

mcollina added the request-ci Add this label to start a Jenkins CI on a PR. label Apr 9, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 9, 2025

resolved pr comment: updated for each loop to for...of loop

90acf08

pimterry approved these changes Apr 11, 2025

View reviewed changes

pimterry added request-ci Add this label to start a Jenkins CI on a PR. author ready PRs that have at least one approval, no pending requests for changes, and a CI started. labels Apr 11, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 11, 2025

		// When the request completes
		req.on('end', common.mustCall());

		// Should receive all data
		assert.strictEqual(receivedData, 64 * 1024 * 16);

	assert.strictEqual(stream.writableFinished, true);
	assert.strictEqual(stream.readableFinished, true);
	assert.strictEqual(stream.writableFinished, true);

	stream.on('close', common.mustCall(() => {
	assert.strictEqual(stream.writableFinished, true);
	}));

http2: add session tracking and graceful server shutdown of http2 server #57586

Are you sure you want to change the base?

http2: add session tracking and graceful server shutdown of http2 server #57586

Conversation

pandeykushagra51 commented Mar 21, 2025 • edited Loading

Purpose

Current Issues

Implementation Details

Behavior Clarification

API Impact

Testing

nodejs-github-bot commented Mar 21, 2025

pandeykushagra51 commented Mar 22, 2025

pandeykushagra51 commented Mar 22, 2025 • edited Loading

mcollina left a comment

Choose a reason for hiding this comment

codecov bot commented Mar 27, 2025 • edited Loading

Codecov Report

lpinca commented Mar 27, 2025

pandeykushagra51 commented Mar 28, 2025

pandeykushagra51 commented Mar 28, 2025

pandeykushagra51 commented Mar 28, 2025

pandeykushagra51 commented Mar 28, 2025

lpinca commented Mar 28, 2025 • edited Loading

pandeykushagra51 commented Mar 28, 2025 • edited Loading

pimterry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pandeykushagra51 commented Mar 28, 2025

lpinca commented Mar 28, 2025

lpinca commented Mar 28, 2025

pandeykushagra51 commented Mar 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pandeykushagra51 Apr 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pandeykushagra51 Apr 7, 2025 • edited Loading

Choose a reason for hiding this comment

pandeykushagra51 Apr 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pandeykushagra51 Apr 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nodejs-github-bot commented Apr 8, 2025

pandeykushagra51 commented Apr 8, 2025

nodejs-github-bot commented Apr 8, 2025

pimterry commented Apr 8, 2025

lpinca commented Apr 8, 2025

nodejs-github-bot commented Apr 8, 2025

nodejs-github-bot commented Apr 9, 2025

mcollina left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nodejs-github-bot commented Apr 9, 2025

pandeykushagra51 commented Apr 9, 2025

nodejs-github-bot commented Apr 11, 2025

nodejs-github-bot commented Apr 11, 2025

nodejs-github-bot commented Apr 12, 2025

pandeykushagra51 commented Mar 21, 2025 •

edited

Loading

pandeykushagra51 commented Mar 22, 2025 •

edited

Loading

codecov bot commented Mar 27, 2025 •

edited

Loading

lpinca commented Mar 28, 2025 •

edited

Loading

pandeykushagra51 commented Mar 28, 2025 •

edited

Loading

pandeykushagra51 Apr 7, 2025 •

edited

Loading

pandeykushagra51 Apr 7, 2025 •

edited

Loading

pandeykushagra51 Apr 7, 2025 •

edited

Loading

pandeykushagra51 Apr 7, 2025 •

edited

Loading