What happened?
The dataset initializer entry point does not return clear, specific errors when
STORAGE_URI is missing or uses an unsupported provider scheme.
File:
pkg/initializers/dataset/__main__.py
For a missing STORAGE_URI, the entry point currently reads the value using:
try:
storage_uri = os.environ[utils.STORAGE_URI_ENV]
except Exception as e:
logging.error("STORAGE_URI env variable must be set.")
raise e
'''
This catches the broad Exception type and re-raises the original KeyError.
As a result, users receive a low-level exception instead of an actionable
configuration error.
For an unsupported storage URI scheme, the entry point currently uses:
```python
case _:
logging.error("STORAGE_URI must have the valid dataset provider")
raise Exception
This raises the generic Exception type without a message containing the invalid
scheme or the supported schemes.
The corresponding unit test also expects the broad Exception type for both
cases. This means an unintended AttributeError, ImportError, or another internal
error could satisfy the test.
Additionally, the dispatcher supports Hugging Face, S3, and Data Cache providers,
but its unit test currently covers only Hugging Face and S3 dispatch.
This proposal only improves dataset initializer entry-point validation, error
reporting, and dispatcher test coverage.
It does not add provider-specific URI-format validation and does not change the
Hugging Face, S3, or Data Cache provider implementations.
What did you expect to happen?
The dataset initializer should validate entry-point configuration before provider
dispatch and return clear ValueError messages.
Expected behavior:
- If STORAGE_URI is missing or empty:
ValueError: STORAGE_URI environment variable must be set
- If STORAGE_URI uses an unsupported scheme:
ValueError: Unsupported dataset storage URI scheme 'invalid': expected one of
'hf', 'cache', or 's3'
-
No provider should be constructed when STORAGE_URI is missing, empty, or uses
an unsupported scheme.
-
The dispatcher unit test should:
- expect ValueError rather than the generic Exception type;
- verify the relevant error messages;
- cover Hugging Face, S3, and Data Cache dispatch;
- verify that only the selected provider is constructed;
- verify that invalid input does not construct any provider.
Environment
Kubernetes version:
Not required to reproduce. This behavior occurs before Kubernetes interaction.
Kubeflow Trainer version:
Current main branch.
Kubeflow Python SDK version:
Not required to reproduce.
Impacted by this bug?
Give it a 👍 We prioritize the issues with most 👍
What happened?
The dataset initializer entry point does not return clear, specific errors when
STORAGE_URI is missing or uses an unsupported provider scheme.
File:
pkg/initializers/dataset/__main__.pyFor a missing
STORAGE_URI, the entry point currently reads the value using:This raises the generic Exception type without a message containing the invalid
scheme or the supported schemes.
The corresponding unit test also expects the broad Exception type for both
cases. This means an unintended
AttributeError,ImportError, or another internalerror could satisfy the test.
Additionally, the dispatcher supports Hugging Face, S3, and Data Cache providers,
but its unit test currently covers only Hugging Face and S3 dispatch.
This proposal only improves dataset initializer entry-point validation, error
reporting, and dispatcher test coverage.
It does not add provider-specific URI-format validation and does not change the
Hugging Face, S3, or Data Cache provider implementations.
What did you expect to happen?
The dataset initializer should validate entry-point configuration before provider
dispatch and return clear ValueError messages.
Expected behavior:
No provider should be constructed when
STORAGE_URIis missing, empty, or usesan unsupported scheme.
The dispatcher unit test should:
Environment
Kubernetes version:
Not required to reproduce. This behavior occurs before Kubernetes interaction.
Kubeflow Trainer version:
Current main branch.
Kubeflow Python SDK version:
Not required to reproduce.
Impacted by this bug?
Give it a 👍 We prioritize the issues with most 👍