[Model Monitoring] Fix TSDB table creation when same credentials are set (ML-11807) #9118
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…set (ML-11807) When set_credentials() is called with the same credentials that are already configured, the code returned early without calling _create_tsdb_tables(). This caused "UndefinedTable" errors if the TSDB tables were deleted or didn't exist yet. The fix ensures _create_tsdb_tables() is always called, even on the early return path. This is safe because all TSDB connector implementations use idempotent table creation: - V3IO: if_exists=v3io_frames.IGNORE - TDEngine: CREATE STABLE IF NOT EXISTS - TimescaleDB: CREATE TABLE IF NOT EXISTS
gtopper
reviewed
Dec 24, 2025
| ) | ||
| # Even if credentials match, ensure TSDB tables exist (ML-11807). | ||
| # This handles cases where tables were deleted or don't exist yet. | ||
| # The create_tables() call is idempotent (uses CREATE TABLE IF NOT EXISTS). |
Collaborator
There was a problem hiding this comment.
This depends on the connector though. Are they all idempotent? They don't all use CREATE TABLE IF NOT EXISTS, that's certain.
Collaborator
There was a problem hiding this comment.
It seems like the answer is that they are idempotent, so just need to clear up the comment.
gtopper
reviewed
Dec 24, 2025
Comment on lines
+1834
to
+1836
| tsdb_profile = self._validate_and_get_tsdb_profile( | ||
| tsdb_profile_name | ||
| ) |
Collaborator
There was a problem hiding this comment.
Do we also need to
secrets_dict[
mlrun.common.schemas.model_monitoring.ProjectSecretKeys.TSDB_PROFILE_NAME
] = tsdb_profile_name?
Member
Author
There was a problem hiding this comment.
No, we don't need to set secrets_dict here.
This is the early return path where credentials are already stored in project secrets:
check_if_credentials_are_set()(line 1824) confirmed credentials exist_is_the_same_cred()(line 1825) confirmed they match the provided values- We return at line 1838, never reaching
store_project_secrets()(line 1880)
The secrets_dict variable is only used later to store secrets, but since the credentials are already stored correctly, we just need to ensure the TSDB tables exist.
gtopper
approved these changes
Dec 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
set_credentials()returns early without creating TSDB tables when the same credentials are already setUndefinedTableerrors if tables were deleted or didn't exist yet_create_tsdb_tables()before the early return, which is safe because all TSDB connectors use idempotent table creation