Enhancement/dd env type override

[Velex158]

What does this PR do?

This PR introduces support for explicitly overriding the detected cloud environment via the DD_ENV_TYPE environment variable.

If DD_ENV_TYPE is set, the mini agent will prioritize this value over the automatically detected environment from read_cloud_env(). Currently supported values are:

• cloudfunction
• azurefunction
• azurespringapp

If the value is not recognized, the existing auto-detection logic remains unchanged.

---

Motivation

We encountered an issue where the environment detection logic incorrectly classified the runtime environment due to the presence of a generic environment variable (FUNCTION_NAME).
The function responsible for this is read_cloud_env()

In our specific case, Azure Functions were misidentified as Google Cloud Functions because FUNCTION_NAME was set by internal tooling. This led to incorrect behavior of the serverless mini agent.

As part of debugging (see support ticket below), we identified that:

• FUNCTION_NAME is too generic to reliably indicate the environment
• The environment detection logic can produce misleading results without clear visibility
• This caused significant debugging effort, as the root cause was not obvious

To resolve this, we:

• Switched internally to AZURE_FUNCTION_NAME
• Added this override mechanism (DD_ENV_TYPE) to allow explicit control

Support ticket:
https://help.datadoghq.com/hc/en-us/requests/2771896?brand_id=284865

Relevant excerpt from investigation:

Our colleagues use the environment variable FUNCTION_NAME in their Azure function which led to the wrong detection of the cloud environment.
So we changed it to AZURE_FUNCTION_NAME and also needed to update all the code where the env var FUNCTION_NAME was used.

FUNCTION_NAME is way too generic to pin it down to GCP only. Additionally it should be documented and error messages should be more precise, as it took significant time to identify the root cause.

---

Additional Notes

• This change is fully backward compatible
• It does not modify existing detection logic unless DD_ENV_TYPE is explicitly set
• Improves debuggability and control in multi-cloud or custom environments
• Helps avoid ambiguous environment detection caused by generic environment variables

---

Describe how to test/QA your changes

Manual testing:

1. Run the mini agent without DD_ENV_TYPE

   • Verify existing environment detection behavior remains unchanged

2. Set DD_ENV_TYPE=azurefunction

   • Verify env_type is correctly overridden to AzureFunction
   • Confirm correct DogStatsD tags:
     origin:azurefunction,dd.origin:azurefunction

3. Set DD_ENV_TYPE=cloudfunction

   • Verify override works for GCP

4. Set an invalid value (e.g. DD_ENV_TYPE=unknown)

   • Verify fallback to auto-detection
   • Confirm debug log message is emitted

5. Reproduce original issue scenario:

   • Set FUNCTION_NAME in environment
   • Confirm that without override → wrong detection
   • With DD_ENV_TYPE → correct behavior

Regression safety:

• No existing logic paths are altered unless the new env var is used
• No breaking changes expected

[Copilot]

Pull request overview

This PR introduces a new environment variable DD_ENV_TYPE that allows users to explicitly override the automatically detected cloud environment type in the serverless mini agent. This addresses a real-world issue where generic environment variables (like FUNCTION_NAME) were causing incorrect environment detection, particularly for Azure Functions being misidentified as Google Cloud Functions.

Changes:

• Added support for explicitly setting environment type via the DD_ENV_TYPE environment variable with three supported values: cloudfunction, azurefunction, and azurespringapp
• Changed env_type from immutable to mutable to allow override capability
• Added validation logic that gracefully falls back to auto-detection if an unrecognized value is provided
• Maintains full backward compatibility—existing auto-detection behavior is unchanged when the new env var is not set

[kathiehuang]

👋 Hi @Velex158, thank you for this PR and the detailed writeup! I have a fix up in libdatadog that addresses the root cause of this and utilizes environment variables that are more cloud-specific to detect the cloud environment: DataDog/libdatadog#1857

This change also improves logging so that the root cause will be made clear in the case of any future environment-detection errors.

Once that change is merged and we do a release of the Serverless Compatibility Layer, you will be able to freely use the FUNCTION_NAME environment variable in your Azure Function without this DD_ENV_TYPE override. Thank you for surfacing this issue and please don't hesitate to reach out if there are any further concerns!