[johanngan]

What was changed

Add an experimental Options.IdleTimeout (and TEMPORAL_LAMBDA_IDLE_TIMEOUT, in whole seconds) that gracefully stops the worker before the invocation deadline once it has had no task in hand for at least the given duration. Tasks are counted using the new experimental SlotUsage API added in #2858. The timeout is a lower bound, with a 20% random jitter added so that workers that went idle together don't all shut down at once.

Why?

Letting Lambda workers shut themselves down on an idle condition can help save money for spiky or infrequent workloads.

Checklist

1. Closes COM-478

2. How was this tested:

• New unit tests added.
• TODO: manual testing with a serverless Lambda WDV with Temporal Cloud, with the following cases:
  • idle shutdown with no work
  • delayed idle shutdown after some work
  • deadline shutdown after continuous workload with no idling
  • deadline shutdown with no activity and idle shutdown disabled

3. Any docs updates needed?
   In-repo docs updated.

[johanngan]

Draft status until we're happy that this client-side tuner approach is the right one

[Sushisource]

Overall my take is we could save a lot of code here by exposing the in flight task count you need from the underlying SDK.

I think it's worth it and had AI sketch what needs to be done and it's pretty small:

1. In trackingSlotSupplier, add a usedSlotCount() that reads len(usedSlots) under the existing mutex. It could also record the last time a slot was marked used or released, under that same lock, which would let the contrib code compute idle time exactly (my other comment)
2. On AggregatedWorker, sum that count across these sub-workers:
   • workflowWorker.worker
   • workflowWorker.localActivityWorker
   • activityWorker.worker
   • sessionWorker.creationWorker and sessionWorker.activityWorker
   • nexusWorker.worker

To expose it, I think we should just do:

• A function in the worker package, such as worker.InFlightTaskCount(w Worker) (int, bool), marked experimental. It would type-assert to *internal.AggregatedWorker. This adds no interface methods, so it can't break anyone.

The only other downside is we need to then cut a release so this package can depend on the updated version w/ the new function.

[johanngan]

Changed the approach of this PR to rely on a base SDK worker.GetSlotUsage API which reads from the worker's internal trackers instead of reimplementing them as a tuner, see #2858.