Fire-and-forget non-essential API calls in Lambda without extending the function’s duration?

I ran into a tricky Lambda behaviour today that I can’t quite square with my mental model of the Node.js runtime.

I had a user request get delayed because a call to flush telemetry to LangSmith was hanging. That’s fine — third-party calls fail — but it’s not OK for this to impact customers. So I updated the code to add a simple timeout around the flush:

try { await Promise.race([ flushPromise, new Promise((_, reject) => setTimeout(() => reject(new Error('LangSmith forceFlush timed out')), 2000) ), ]); } catch {}

It worked locally, so I deployed it — then immediately started getting P50 alarms. Every Lambda was taking exactly 2 seconds to finish. The user responses were fast (so the handler returned), but Lambda kept the function “open” until the loser of the race finished its internal work. I get why — Promise.race doesn’t cancel anything — so I removed the race and switched to this:

setTimeout(() => { void flushPromise.catch(console.warn); }, 2000);

But I hit the same problem. Even this delayed call — not awaited, not referenced — caused all Lambdas to report a ~2s duration. Removing it fixed the problem immediately.

So here’s what I’m trying to understand:

What is the correct way to fire-and-forget a non-essential API call in Node.js Lambda, without forcing Lambda to wait for the timeout window?

Constraints:

• I can’t use callbackWaitsForEmptyEventLoop = false because some handlers stream responses.
• I don’t want telemetry to block customer-visible work.
• I don’t want to eat a fixed delay on every invocation.
• I don’t want dangling timers or promises that keep the event loop “dirty.”

I’m fine if the flush doesn’t complete — it’s best-effort telemetry.

I feel like there must be a clean, accepted pattern for this — something that won’t hold the Lambda open and won’t interfere with streaming responses.

What’s the recommended approach for truly non-blocking, best-effort background calls in Lambda?

I should note, for the purposes of this discussion - this is can be considered a basic LLM chat handler. SO really, i'd expect this to be trivial! Hoping i'm missing something, maybe things have evolved and there is a better pattern for this!