Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicitly allow fail-fast for invalid enum values #2766

Closed
wants to merge 12 commits into from
4 changes: 3 additions & 1 deletion specification/sdk-environment-variables.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,9 @@ If an SDK chooses to support an integer-valued environment variable, it SHOULD s
### Enum value

For variables which accept a known value out of a set, i.e., an enum value, SDK implementations MAY support additional values not listed here.
For variables accepting an enum value, if the user provides a value the SDK does not recognize, the SDK MUST generate a warning and gracefully ignore the setting.
For variables accepting an enum value, if the user provides a value the SDK does not recognize,
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure why this behavior is only under Enum values, shouldn't there be a common error behavior for all env values? What if integer var is set to blah?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was thinking about it as well, but I want to avoid scope creep in this PR. Even right now it is not clear how to proceed

the SDK MUST generate a warning and gracefully ignore the setting,
or _fail fast_ and cause the application to fail at startup, but MUST NOT cause the application to fail later at run time.
pellared marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this change is necessary - #2817 (comment)


If a null object (empty, no-op) value is acceptable, then the enum value representing it MUST be `"none"`.

Expand Down