fix(connection): reject connector_type values that violate platform slug pattern (BLDX-1294)#939
Merged
Conversation
…lug pattern (BLDX-1294)
Connection.creator and Connection.creator_async now validate
connector_type.value against the same ^[a-z0-9-]+$ pattern the Atlan
platform's server-side asset-import (RAB) path enforces. Mirrors the
Java SDK constraint.
Without this, users could create Connections via pyatlan with slugs
containing underscores (e.g. 'dev_cmdr'), dots, whitespace, or other
characters that the platform rejects later at import time — leaving
phantom Connection rows in Atlas. Reported in APP-2263 where a customer
created 'dev_cmdr' via pyatlan and then watched RAB reject every
subsequent asset-import that referenced it.
Built-in AtlanConnectorType members are all already kebab-case and pass
the check. The validator only bites custom types created via
CREATE_CUSTOM(value=...) — exactly the surface the customer hit.
Error message points users at the simple fix:
Invalid connector_type value 'dev_cmdr': must match pattern
'^[a-z0-9-]+$' (lower-case alphanumerics and hyphens only). ...
Replace any underscores with hyphens (e.g. 'dev_cmdr' -> 'dev-cmdr').
Validation lives in pyatlan/model/assets/connection.py as a module-level
helper (_validate_connector_type_value) so pyatlan_v9 can import the
same source-of-truth. Updated both the generated v9 connection.py and
the _overlays/connection.py template so the next regeneration preserves
the fix.
Tests:
- pyatlan: 6 bad-value parametrized cases (underscore / dot / whitespace /
slash / special-char / trailing underscore), 6 good-value regression
pins (hyphen / built-in-like / multi-hyphen / single-char / alphanum /
digit-prefix), built-in-connector-type regression, async-creator
rejection.
- pyatlan_v9: parametrized bad-values + valid-value regression.
… invalid connection QN (BLDX-1294) Aligns with the Java SDK convention from atlanhq/atlan-java#2504 which added ErrorCode.INVALID_CONNECTION_QN (ATLAN-JAVA-400-055) for the same class of failure. Cross-SDK error reporting now matches: typed exception class + stable error code that customer log-aggregation can group on. Replaces the bare ValueError raised by _validate_connector_type_value with InvalidRequestError carrying ErrorCode.INVALID_CONNECTION_QN (ATLAN-PYTHON-400-079). Message + user-action mirror the Java side. Tests updated to assert on: - isinstance(exc, InvalidRequestError) - "ATLAN-PYTHON-400-079" in str(exc) - bad slug surfaced in exc message
…nnection QN validation (BLDX-1294)
`TestId.make_unique` was emitting ids like ``psdk_<INPUT>_<SESSION>`` —
mixed-case, underscore-separated, and uppercase-allowed session
alphabet. After the new ``^[a-z0-9-]+$`` validation in
``Connection.creator``/``creator_async`` (ATLAN-PYTHON-400-079), every
integration fixture that feeds ``MODULE_NAME`` into
``AtlanConnectorType.CREATE_CUSTOM(value=...)`` started failing setup
because the slug contained underscores and/or uppercase letters.
Changes:
- ``TestId.make_unique`` (both ``pyatlan/test_utils`` and the
``tests/integration`` / ``tests_v9/integration`` mirrors) now
lowercases the input, swaps underscores for hyphens, uses a
lowercase-only nanoid alphabet, and joins with hyphens:
``psdk-<slug>-<session>`` (and ``psdkv9-...`` for v9).
- Custom-connection fixture slugs switched from
``f"{MODULE_NAME}_type"`` → ``f"{MODULE_NAME}-type"`` (and the
matching assertions) in:
- ``tests/integration/connection_test.py``
- ``tests/integration/aio/test_connection.py``
- ``tests_v9/integration/connection_test.py``
- ``tests_v9/integration/aio/test_connection.py``
- Callers that previously matched on the literal ``psdk_*`` / ``psdkv9_*``
display-name prefix (token cleanup, search-pagination exclusion
wildcards) now also match the new hyphenated form so they keep
working across pre/post-BLDX-1294 runs.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Connection.creatorandConnection.creator_async(both pyatlan and pyatlan_v9) now validateconnector_type.valueagainst^[a-z0-9-]+$— the same pattern the Atlan platform's server-side asset-import (RAB) path enforces. Mirrors the existing Java SDK constraint.Linear: BLDX-1294
Origin: APP-2263 — customer created
dev_cmdrconnection via pyatlan, RAB then rejected every asset-import referencing it, leaving phantomConnectionrows in Atlas.Why
Today, pyatlan accepts any string a customer passes to
AtlanConnectorType.CREATE_CUSTOM(value=...). The slug ends up embedded inconnectionQualifiedName(default/{slug}/{epoch}). Later, when assets are imported under that connection, the server-side RAB validator rejects the QN because the slug doesn't match^[a-z0-9-]+$. Symptoms reported:dev_cmdrvia pyatlan → succeeds.Connectionrow remains in Atlas; customer has to manually clean up.The Java SDK was tightened to enforce the same regex at creation time. pyatlan was left behind.
What changes
pyatlan/model/assets/connection.py— new module-level_CONNECTOR_TYPE_VALUE_PATTERN+_validate_connector_type_value()helper. BothConnection.creatorandConnection.creator_asyncnow call it right aftervalidate_required_fields.pyatlan_v9/model/assets/connection.py— imports the same helper from pyatlan (single source of truth) and calls it in both creator paths.pyatlan_v9/model/assets/_overlays/connection.py— overlay updated so the next codegen regen preserves the fix.Built-in
AtlanConnectorTypemembers (SNOWFLAKE,MYSQL,AMAZON_MSK, …) are all kebab-case and pass the check unchanged. The validator only bites custom types created viaCREATE_CUSTOM(value=...)— exactly the surface the customer hit.Test plan
pyatlan (
tests/unit/model/connection_test.py)dev_cmdr,dev.cmdr,dev cmdr,dev/cmdr,dev@cmdr,dev_— each must raiseValueError("Invalid connector_type value ...")dev-cmdr,snowflake,amazon-msk,a,abc123,123-abc-456— all must construct successfullytest_creator_accepts_builtin_connector_types— built-inSNOWFLAKEcontinues to work (regression guard)test_creator_async_rejects_invalid_connector_type_value— async path enforces the same rulepyatlan_v9 (
tests_v9/unit/model/connection_test.py)Regression
tests/unit/model/+tests_v9/unit/model/.Notes
AtlanConnectorType.CREATE_CUSTOMalready lowercases input, so the validator never seesDev-CMDR— it's seen asdev-cmdr(valid). The validator catches what survives lowercasing: underscores, dots, special chars, whitespace.CREATE_CUSTOMitself.CREATE_CUSTOMis also used internally by_get_connector_type_from_qualified_nameto parse existing QNs — validating there would break the ability to read connections that already have non-conforming slugs in Atlas (pre-existing state should remain readable; only new creations are tightened).🤖 Generated with Claude Code