Acceptance test: TestAccScimWorkspaceMappingsDataSource_withCreatedMapping asserts slug against UUID

[roh26it]

Summary

TestAccScimWorkspaceMappingsDataSource_withCreatedMapping fails against the live API. It asserts an equality between two different identifier namespaces that the provider — by design — never satisfies.

scim_workspace_mappings_data_source_test.go:41: Step 1/1 error: Check failed: Check 4/5 error:
data.portkey_scim_workspace_mappings.filtered:
  Attribute 'mappings.0.workspace_id' expected "ws-tf-acc-329a4f", got "d4f92461-0e9b-4c91-9b70-eb2d19c099ed"

This is a test bug, not a provider bug. Surfaced while reviewing #56 (unrelated change); reproduced on main at b1bc9f0.

Root cause

The failing check is in internal/provider/scim_workspace_mappings_data_source_test.go:

resource.TestCheckResourceAttrPair(
    "data.portkey_scim_workspace_mappings.filtered", "mappings.0.workspace_id",
    "portkey_workspace.test", "id",
),

portkey_workspace.id holds the slug (ws-tf-acc-329a4f), while the SCIM mappings API reports workspace_id as the workspace UUID. The data source reports the API's value verbatim, which is correct.

The split is already documented in three places in the codebase:

• scim_workspace_mapping_resource.go:167-172 — "The Portkey API normalizes the value on the way back (e.g. slug ws-foo-abcd12 comes back as the workspace's UUID)"
• scim_workspace_mapping_resource.go:214-216 — "workspace_id is preserved verbatim from state ... rewriting it here would surface as drift"
• scim_workspace_mappings_data_source.go:132-136 — "The API's workspace_id filter only matches the workspace's UUID form, not the slug"

The resource deliberately preserves the user-authored slug. The data source has no authored value to preserve for mappings[*].workspace_id, so it reports the UUID. The assertion contradicts documented behaviour.

The test was added in 6b0e52c (#36) and never modified since, so it most likely never passed. It went unnoticed because CI does not run acceptance tests (TF_ACC unset), so this only shows up in a local run.

Proposed fix

Assert the shape rather than a false equality, so the check doesn't degrade into a vacuous TestCheckResourceAttrSet:

// The mappings API reports workspace_id in UUID form, while
// portkey_workspace.id is the slug — the two identifier namespaces are
// documented in the resource's Create/Read and in this data source's Read,
// so they can't be compared directly. Assert the shape instead: proof the
// data source surfaced the API's value verbatim rather than echoing back
// the slug we filtered on.
resource.TestMatchResourceAttr(
    "data.portkey_scim_workspace_mappings.filtered", "mappings.0.workspace_id",
    regexp.MustCompile(`^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$`),
),

The test keeps real coverage from the surrounding assertions: mappings.# == 1 proves the slug→UUID filter resolution worked, and the mappings.0.id ↔ portkey_scim_workspace_mapping.test.id pair proves it is the mapping just created. The UUID regex adds that the data source did not simply echo the filter input back.

Verified locally — with this change the SCIM suite is green:

--- PASS: TestAccScimWorkspaceMappingResource_basic (11.00s)
--- PASS: TestAccScimWorkspaceMappingResource_roleReplace (15.21s)
--- PASS: TestAccScimWorkspaceMappingsDataSource_basic (1.61s)
--- PASS: TestAccScimWorkspaceMappingsDataSource_withCreatedMapping (12.38s)

(_byID skips without TEST_SCIM_GROUP_ID.)

Related gap (separate scope)

The reason the original assertion looks plausible is that there is currently no way to express a workspace's UUID in HCL. portkey_workspace exposes only id (the slug), but client.Workspace already carries both ID and Slug.

A computed uuid attribute on portkey_workspace would let users join workspaces to SCIM mappings in a for_each, and would let this test perform a genuine TestCheckResourceAttrPair. That is a public schema addition requiring docs, so it should not ride along with the test fix — filing here for visibility.

Other pre-existing failures

A full local acceptance run on main (183 tests) had four other failures, all environmental rather than code defects, listed here so they aren't re-diagnosed:

• TestAccWorkspaceSecuritySettingsResource_basic and ..._partialPreservesOtherFields — API 400: "Workspace override is not enabled for the following section(s): logs, data_visibility" (test-org configuration)
• TestAccWorkspaceMemberResource_basic
• TestAccPromptResource_updateName — API 400 Invalid value on parameters

Worth splitting into their own issues if we want the suite green.