fix(types): allow send() to accept PromiseLike payloads - #6526

Can you plz fix the lint error?

@skdas20 would you like to finalize this PR?

Force-pushed a rebase + fix for the issues raised here:

• Rebased onto current main to resolve the merge conflict, and fixed the lint error (trailing whitespace) @jean-michelet flagged.
• Addressed the Copilot review comment: the type change alone claimed send() accepts a PromiseLike<T>, but runtime never actually resolved one — it would have just serialized the Promise object itself. Added the missing runtime support in Reply.prototype.send (reusing the existing wrap-thenable path that already handles this for handler return values), plus a couple of runtime tests (test/internals/reply.test.js) covering resolve and reject.
• Updated the other type tests (type-provider.tst.ts, instance.tst.ts) whose expected send() signatures were affected by the widened type, and adjusted the test-typescript fixtures for the tst.ts rename that landed on main since this PR was opened.

All type tests (tstyche) and the full unit suite pass locally.

Thanks @Eomm — added all four, plus one more that writing them turned up.

Behaviour of the four cases (all now asserted):

1. return reply.send(Promise.resolve('asd')) from a sync handler → asd
2. reply.send(Promise.resolve('asd')) inside an async handler → asd
3. send(Promise.resolve('one')) then send(Promise.resolve('two')) → one, second warns FST_ERR_REP_ALREADY_SENT (same as double-send with plain values)
4. send(wait(1000) → 'one') then send(wait(500) → 'two') → two

Case 4 is worth a maintainer opinion: with promise payloads the winner is whichever settles first, not whichever send() was called first, because the payload isn't known until settlement. I think that's the only coherent semantic here (and it matches how wrap-thenable already behaves for returned promises), but it is a genuine difference from the plain-value case, so I've asserted it explicitly rather than left it implicit.

The extra fix: case 3/4 exposed that when send() bails out via the this.sent === true branch, a thenable payload was dropped with no handler ever attached — so if it later rejected, that surfaced as an unhandled rejection, which is fatal by default on modern Node. Since this PR makes promises a supported payload type, that path is now reachable through normal use, so send() now attaches a handler that logs the late rejection instead. Test included (a promise rejecting after the reply was sent is logged, not left unhandled).

Full unit suite green locally (2064 passing), lint clean. Happy to split the unhandled-rejection fix into its own PR if you'd rather keep this one narrow.

@skdas20 As soon as you have time, can you resolve conflicts?

@Tony133 done — rebased onto main, conflicts resolved.

The only conflict was in test/internals/reply.test.js, where #6879's new quoted-charset= test and my promise-payload tests were both appended at the end of the file. Both are kept.

Green locally after the rebase: 89 unit tests in reply.test.js, tstyche 1284 assertions across 16 files, lint clean.

@Eomm the question from my earlier comment is still open whenever you have a moment: with two promise payloads, the one that settles first wins rather than the one send() was called for first (asserted in calling reply.send(promise) twice is settle-ordered, not call-ordered). It's the only coherent semantic I could find, since the payload isn't known until settlement, but it does differ from the plain-value case, so I'd rather it be a deliberate decision than an accident of implementation.

Can you change the PR description?

This is a full implementation of that feature.

I'm not exactly sure we should land this, because what this wants to achieve is already supported with a slightly different API: return the thenable from the handler. Why adding it?

Description rewritten — it described the original types-only diff, which was stale. It now states plainly that this is a feature implementation plus a separable robustness fix.

On whether it should land: your instinct is right, and I don't have a user-facing justification to offer. There is no linked issue and no reported problem behind this PR. It began as a types-only widening, and the runtime work exists only because that widened type would otherwise have described behaviour send() did not implement — the type would have been lying. That's a reason the two halves can't ship apart; it is not a reason the feature is needed.

Since return thenable is the supported idiom and already covers the use case, I think the honest options are:

1. Close it. return is the API, send() stays value-only, and nothing is owed. I'd have no objection — a second path to the same outcome is API surface and maintenance for no new capability, plus it forces you to take a position on the settle-order semantics above.
2. Take only the unhandled-rejection fix, as a small standalone PR. That one stands on its own: a JS user can pass a promise to send() today regardless of the types, and if the reply was already sent, the payload is dropped with no handler attached, so a later rejection takes the process down. That's a defect independent of whether send(promise) is ever a supported API.
3. Land the whole thing, if you see a case I don't.

I'd suggest (2). Happy to open it as a separate PR against a clean branch and close this one — just say the word rather than my assuming.

@mcollina I've opened #6936 with just the unhandled-rejection half — option (2) from my previous comment. It's four lines plus a test and doesn't touch SendArgs or add any API, so it can be judged without deciding anything about send(promise).

Leaving this PR open for now in case you want the feature, but I have no attachment to it — if your answer is that return thenable is the API, closing this is the right outcome and #6936 covers the part that's a defect either way.