Skip to content

Conversation

@hunter-ni
Copy link
Contributor

@hunter-ni hunter-ni commented Dec 1, 2025

What does this Pull Request accomplish?

This set of changes adds support for the ClusterId environment variable (without the NIDiscovery_ prefix), given that the Discovery Service recognizes an environment variable of that prefix-less name as well.

This change is being made in response to this comment on PR #242.

Why should this Pull Request be merged?

This PR adds greater robustness in properly handling an environment variable being set to specify the Cluster ID of the Discovery Service.

What testing has been done?

  • Verified that the DiscoveryClient was able to successfully interact with the Discovery Service that was launched with the ClusterId environment variable set
  • Verified that the DiscoveryClient was still able to successfully interact with a Discovery Service that was launched with the NIDiscovery_ClusterID environment variable

@github-actions
Copy link
Contributor

github-actions bot commented Dec 1, 2025

Test Results

  120 files  ±0    120 suites  ±0   3m 28s ⏱️ -1s
  249 tests ±0    247 ✅ ±0   2 💤 ±0  0 ❌ ±0 
2 490 runs  ±0  2 460 ✅ ±0  30 💤 ±0  0 ❌ ±0 

Results for commit 41e5abd. ± Comparison against base commit ec5c154.

♻️ This comment has been updated with latest results.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR enhances the Discovery Client to support both the prefixed (NIDISCOVERY_CLUSTERID) and prefix-less (CLUSTERID) environment variable names for specifying the Cluster ID, aligning with the Discovery Service's own behavior. This change improves robustness and compatibility when interacting with the Discovery Service.

Key changes:

  • Introduced constants for the environment variable prefix and cluster ID name
  • Added fallback logic to check both prefixed and non-prefixed environment variable names
  • Includes inline comment noting future consideration for case-insensitive environment variable lookups

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@hunter-ni hunter-ni requested a review from nick-beer December 1, 2025 20:22
@hunter-ni hunter-ni marked this pull request as ready for review December 17, 2025 15:16
@hunter-ni hunter-ni requested a review from a team December 17, 2025 15:16
def _get_discovery_service_address() -> str:
cluster_id = os.environ.get("NIDISCOVERY_CLUSTERID")
# To support operating systems other than Windows (and match Discovery Service behavior),
# we would likely want to make this check case-insensitive.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we document this for users? If we use shout-case there, then all OSes have the same casing for this variable and we can use os.environ directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe @nick-beer's original comment (precipitating this change + comment) was that we would want to match here whatever the Discovery Service itself would be anticipated to actually support, which would be the environment variable of this given name (with optional prefix) irrespective of case. I don't have any specific insight on the question of existing documentation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the server is going to use PascalCase, then you're better off using PascalCase in the Python and LV packages so that it works regardless of whether environment variables are case-sensitive or case-insensitive. However, a lot of software avoids this situation by using all-caps for environment variables everywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To summarize (and confirm that I'm on the same page):

Nick's comment indicates that the Discovery Service itself is explicitly designed to look for this environment variable in a case-insensitive manner (regardless of operating system). To your point though, existing Discovery Service code does use PascalCase when it needs to reference ClusterId and the NIDiscovery prefix, so we can use that casing here for consistency with the server code.

@hunter-ni hunter-ni requested a review from a team December 17, 2025 16:58
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.

4 participants