refactor(native): Fail on empty or non-existent config environment variable

[nmahadevuni]

Description

This change is to report error when config properties reader finds an empty or non-existent envrionment variable.

Motivation and Context

If environment variable is empty or non-existent, we are quietly discarding it and loading the catalog which is causing issues while accessing the catalog assuming all is right with it.

Impact

No impact

Test Plan

Added test in ConfigTest.cpp

== NO RELEASE NOTE ==

[sourcery-ai]

Reviewer's Guide

This PR strengthens configuration handling by making the config reader fail fast when encountering empty or non-existent environment variables, and extends unit tests to verify both normal substitution behavior and the new error cases.

File-Level Changes

Change	Details	Files
Config reader now treats empty or missing environment variables as hard errors instead of silently accepting them.	Updated environment-variable extraction to check for both null and empty values returned from getenv Replaced warning log on empty env var with a VELOX_USER_FAIL throwing an error when the env var is missing or empty Kept successful substitution behavior unchanged when a valid non-empty env var is present	presto-native-execution/presto_cpp/main/common/ConfigReader.cpp
ReadConfig environment variable tests expanded to cover invalid env var scenarios and verify error behavior.	Stopped setting the previously-used empty environment variable in the happy-path test setup and removed it from the expected properties map Introduced a reusable helper lambda to write a config file and assert that readConfig throws with a specific error message Added tests to validate that readConfig throws when an environment variable is configured but empty, and when it is configured but not defined in the environment Introduced a constant for a non-existent environment variable name to drive the failure-path test	presto-native-execution/presto_cpp/main/common/tests/ConfigTest.cpp

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• The new error message for invalid environment variables conflates non-existent and empty cases; consider differentiating these in the message (or including the actual value for the empty case) to make debugging misconfigurations easier.
• In readConfigEnvVarTest, the testInvalidEnvVar helper hardcodes the expected error strings; you could construct the expected message using the variable name to avoid duplication and keep the test resilient to future wording changes.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new error message for invalid environment variables conflates non-existent and empty cases; consider differentiating these in the message (or including the actual value for the empty case) to make debugging misconfigurations easier.
- In `readConfigEnvVarTest`, the `testInvalidEnvVar` helper hardcodes the expected error strings; you could construct the expected message using the variable name to avoid duplication and keep the test resilient to future wording changes.

## Individual Comments

### Comment 1
<location> `presto-native-execution/presto_cpp/main/common/tests/ConfigTest.cpp:356-364` </location>
<code_context>
   ASSERT_EQ(properties, expected);

+  // Empty env var
+  auto testInvalidEnvVar = [this](
+                               const std::string& fileContent,
+                               const std::string& expectedErrorMsg) {
+    cleanupConfigFilePath();
+    setUpConfigFilePath();
+    writeConfigFile(fileContent);
+    VELOX_ASSERT_THROW(
+        presto::util::readConfig(configFilePath_), expectedErrorMsg);
+  };
+
+  setenv(kEmptyEnvVarName.c_str(), "", 1);
</code_context>

<issue_to_address>
**suggestion (testing):** Consider making the invalid env-var assertions more explicit and slightly less brittle than matching the full error string.

`testInvalidEnvVar` currently uses `VELOX_ASSERT_THROW` with the full error message, which makes the test brittle to minor wording changes. If supported, it would be better to assert on a regex or substring that checks only the key parts (e.g., env var name and that it is missing/empty). If you intentionally want to lock down the exact user-facing text, please add a brief comment to document that choice for future maintainers.

Suggested implementation:

```cpp
  std::unordered_map<std::string, std::string> expected{
      {kEnvVarKey, kEnvVarValue},
      {kEnvVarKey2, "${PRESTO_READ_CONFIG_TEST_VAR"},
      {kEnvVarKey3, "PRESTO_READ_CONFIG_TEST_VAR}"},
      {kNoEnvVarKey, "${}"}};
  ASSERT_EQ(properties, expected);

  // Empty env var: use a substring error match to keep the test robust
  // against minor wording changes while still validating the key behavior.
  auto testInvalidEnvVar =
      [this](const std::string& fileContent,
             const std::string& expectedErrorPattern) {
        cleanupConfigFilePath();
        setUpConfigFilePath();
        writeConfigFile(fileContent);
        VELOX_ASSERT_THROW(
            presto::util::readConfig(configFilePath_), expectedErrorPattern);
      };

  // Set the env var to an empty string and verify that readConfig fails.
  setenv(kEmptyEnvVarName.c_str(), "", 1);
  testInvalidEnvVar(
      kEnvVarKey + "=${" + kEmptyEnvVarName + "}",
      // Only assert on the presence of the env-var name in the error message
      // instead of the full user-facing string to avoid brittle tests.
      kEmptyEnvVarName);

```

1. Ensure that `kEmptyEnvVarName` is defined in this test file (as it was in the developer's original change) and refers to the env-var key used in the config string.
2. If `setenv` is not already used elsewhere in this file, make sure `<cstdlib>` (or the appropriate header providing `setenv`) is included at the top of the file.
3. If more invalid-env-var cases are desired (e.g., unset variable, malformed `${}`), you can add more `testInvalidEnvVar` calls with different `fileContent` strings and stable `expectedErrorPattern` substrings.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[aditi-pandit]

@nmahadevuni : This does have the side effect that we were allowing empty values in the past, but will not going forth.

Can you give more information about the context in which you encountered the errors ? That would give us more understanding of how to change this logic.

[nmahadevuni]

This is only for configs that are set using the env vars. In recent internal issues, due to dynamic catalog loading, we have seen issues where env vars were not set correctly and logs didn't give any clue as to what went wrong. We want to catch such issues while loading catalog.