Add runtime type information to worker heartbeats

[Sushisource]

What changed?
Title

Why?
Help us understand customer environments. SDKs will include an opt-out flag.

Breaking changes

Server PR

[github-actions]

Opengrep — new findings

Severity	Location	Rule	Message
ERROR	.github/workflows/create-release.yml:25	security.gha.missing-explicit-permissions-temporal	No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).
ERROR	.github/workflows/create-release.yml:30	security.gha.missing-explicit-permissions-temporal	No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).
ERROR	.github/workflows/create-release.yml:99	security.gha.missing-explicit-permissions-temporal	No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).
ERROR	.github/workflows/trigger-api-go-update.yml:16	security.gha.missing-explicit-permissions-temporal	No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).

---

Suppress findings

Add a noopengrep comment on the line before the finding:

# noopengrep: <rule-id>

[02strich]

Is there more than one type possible? Like python in docker?

[yuandrew]

the field in the heartbeat is repeated, so we can include multiple

// be repeated for scenarios like "Python inside a Lambda".

[yuandrew]

Actually, does it make sense to have RuntimeType type = 1; to be repeated here? Would we expect the version of multiple runtimes in the heartbeat to diverge, or will they always be the same?

[jmaeagle99]

Should there be an UnspecifiedPlatform in case someone is running on something that isn't Windows, Linux, or MacOS (e.g. BSD). Idk if we'd want an optional name field (so then is it really unspecified?) and version. Maybe named OtherPlatform?

[Sushisource]

OtherPlatform makes sense

[jmaeagle99]

I think these are overly specific and orthogonal sometimes:

• Are we going to list every single branded cloud *aaS environment we want to know about? For example, Lambda, ECS, EKS, Fargate, EC2, etc. That's just AWS and probably doesn't enumerate all of their compute environments. I know Azure its own variety (e.g. Functions, App Service for Windows, App Service for Linux (yes, they are separate), Container Apps, Kubernetes, Virtual Machines, etc). I'm sure GCP has their own too. It really depends on the granularity that is needed.
• Even within one *aaS environment, there are multiple deployment technologies that are allowed. For example, Lambda supports both container images (which might not just be Docker) and zip archives: https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-lambda-function.html

I think that the cloud service should at least be separate from the deployment/delivery technology.

[Sushisource]

I was just going with what we're supporting for serverless right so far, but, yes totally valid point.

The fact that it's repeated allows for things like docker-in-lambda.

However, maybe we don't really care about this since we have serverless usage info via the fact that they're registered as configurations on the server already. At the same time, I dunno how well we can correlate that with other SDK info and having it all in once place is nice.

So, kinda my inclination is this can just be things we know we care about, and not everything else, and we can be fine leaving it at that, but I'm definitely open to other suggestions.

[02strich]

+1 to this being independent of the serverless config as that will be harder to reason about in a few cases. I would also probably be more generous in the API definition than we'll be distinguishing in the code for now - so having Lambda, ECS, EKS, EC2, AgentCore Runtime should cover AWS.

The one question this raises for me, whether it would be simpler to have this a string field, but I am not sold on that personally.

[Sushisource]

I want to avoid strings because they will bloat wire size significantly (as well as, obviously, be hard to make consistent).

I'll add more variants.

[jmaeagle99]

Some of these are "runtimes" and some of these are languages. Should we separate them as such? It'll make it easier to describe things like:

• TS on Node vs TS on Bun
• Java on JVM vs Kotlin on JVM

So I think RuntimeType should be:

• RUNTIME_TYPE_UNSPECIFIED
• RUNTIME_TYPE_NATIVE (for Go and Rust)
• RUNTIME_TYPE_JVM
• RUNTIME_TYPE_CPYTHON
• RUNTIME_TYPE_NODE (for TS)
• RUNTIME_TYPE_BUN (for TS)
• RUNTIME_TYPE_DOTNET_CORE (for .NET)
• RUNTIME_TYPE_DOTNET_FRAMEWORK (for .NET)
• RUNTIME_TYPE_CRUBY
• RUNTIME_TYPE_ZEND (for PHP)

The above are actual runtimes, independent of which languages run on them. For languages, we either just infer that from the sdk_name or create a separate enum and message for those.

[Sushisource]

Ya, makes sense

[Sushisource]

Updated (though used RoadRunner instead of Zend since the PHP SDK only works w/ RoadRunner)