Feature request: add access method to `coldStart` field in the `Utility` class

[am29d]

Use case

I'd like to have a method that will return the current value of the coldStart field of the Utility class without changing the value. Right now both isColdStart and getColdStart changes the value when called. As mentioned in #3278 we can't access the flag without changing it.

Solution/User Experience

I propose to change isColdStart to return the coldStart value without changing it which would also reflect its meaning.

Alternative solutions

Change `coldstart` field to protected.

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[am29d]

I am going forward and set the coldStart field to protected for now. We will eventually circle back and remove the Utility class in the future.

[dreamorosi]

The current design was built on the assumption that each utility instance (i.e. Logger) would access/visit that value only once per initialization. With that in mind, it made sense to make it this way.

I know this request comes related to the work in #3278, which now requires us to access the cold start value twice, so it makes sense to refactor.

Two non-invasive options would be:

1. make this value protected so you can access it directly from the Logger
2. make sure you're calling the sampling logic after the addContext, and then access the cold start value at this.powertoolsLogData.lambdaContext?.coldStart.

I think both are not great and kind of defeat the purpose of having that Utility class abstraction. For context, we added that class over 3 years ago in #484 as an early effort to consolidate common logic between core utilities in a shared parent class.

Despite this initial push however, the core utilities have evolved to have their own independent logic over time and we barely ever touched that Utility class. In hindsight, looking at current usage, this might've been a case of premature optimization

To move forward, I think we have two options, assuming we don't want to pursue any of the suboptimal ones above:

Option 1

Remove this Utility class entirely, and move back the logic into each core utility. In its current state this class only adds cognitive complexity to the mix and provides little deduplication value.

The two methods getColdStart() and isColdStart() could be consolidated, and the getDefaultServiceName() method is just an accessor, so in practice we'd only need two properties:

• isColdStart
• defaultServiceName
  and a method that flips it

Option 2

We keep the Utility class and we actually make it useful.

Specifically, we could implement new logic that actually keeps track of whether a certain invocation is a cold start or not based on the environment rather than on an internal state alone.

Right now, if for some reason you have two independent Logger instances, or are using Powertools in a compute environment that supports multiple requests at once, the cold start logic is completely broken since it relies on the order of access for the property for each instance of the class.

We could instead make the cold start scoped to a specific request and do something like this:

coldStartMap = new Map<string, boolean>();

public isColdStart() {
  const requestId = process.env._X_AMZN_REQUEST_ID;
  if (!requestId) {
    return true; // this is during init, so we it's THE cold start
  }
  if (this.coldStartMap.size === 0) {
    this.coldStartMap.set(requestId, true); // this is the first request being seen
    return true;
  }
  this.coldStartMap.set(requestId, false); // these are all the others
  return false;
}

This way we rely on the presence and value of _X_AMZN_REQUEST_ID and use it to keep a state of whether this is the first request we're seeing (aka a cold start) or if it's a subsequent one.

This logic would have to exist outside of the Logger instance and its parents, so in practice we'd have to create some shared context.

---

What do we think?

Btw I am okay also with making a quick change and make it protected to progress on the other issue, have a discussion here, and then go back to change if we agree on something.