Skip to content

Conversation

@jchrostek-dd
Copy link
Contributor

Task

https://datadoghq.atlassian.net/browse/SVLS-7836?atlOrigin=eyJpIjoiMWNmZTMzOGE4NGEwNDE4MTk5Njk0N2ZmMmU3MzExMjgiLCJwIjoiaiJ9

Overview

The extension neither creates SnapStart spans nor emits SnapStart metrics. This PR adds both.

When a lambda with snapshot enabled is invoked for the first time, we get Platform.RestoreStart and Platform.RestoreReport. These effectively take the place of Platform.InitStart and Platform.InitReport events, so our code flow is pretty much identical to how we handle the cold start span and duration metric.

Note - When a SnapStart instance is restored, we actually receive the Platform.InitStart and Platform.InitReport events in addition to the Platform.RestoreStart and Platform.RestoreReport. However, the Init events are not from the sandbox starting for that invoke. These Init events are actually generated from when the Snapshot is created. This is very misleading - You can see that this trace is more than 3 hours long. The lambda was invoked more than 3 hours after the snapshot version was created. (This is the current experience).

Testing

I deployed my own extension with the changes and confirmed we are now getting a restore span and not an init span, link.

@jchrostek-dd jchrostek-dd requested a review from a team as a code owner October 30, 2025 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants