[Lyin-OTTF]

Description

Fixes #3705.

A managed session never runs when the control plane reports a namespaced owner id:

Managed session turn failed: sessionId=sess_62a374ad4da7, error=Invalid agentId
'dpa-namespace:default:default-92145f4c-...-sess_62a374ad4da7': must match [A-Za-z0-9._-]+ ...

HarnessAgentBuildService#sessionLogAgentId joins three parts:

return DP_AGENT_PREFIX + session.ownerId() + "-" + session.agentId() + "-" + session.id();

and the result is passed to HarnessAgent.Builder#agentId(...), which validates it through AgentBase.normalizeAgentId. The colon comes from the owner id (namespace:default), not from the agent id, and the validation rejects the whole assembled value.

Change

Took the first option from the issue: clean up on assembly, not widen the pattern.

Widening [A-Za-z0-9._-] is not safe here. normalizeAgentId documents the id as a single path/namespace segment, HarnessAgent.Builder#agentId pins it as the stable namespace key for composite-filesystem paths, and : is invalid in Windows paths regardless. So the assembled parts now go through a segment mapper that replaces anything outside the accepted alphabet with -:

dpa-namespace:default:default-92145f4c-...-sess_62a374ad4da7
dpa-namespace-default-default-92145f4c-...-sess_62a374ad4da7

Mapping instead of stripping keeps the owner, agent and session parts readable and distinct (dropping the namespace would let two namespaces with the same name collide). An id that was already valid is returned unchanged, so nothing changes for owners without a namespace prefix.

Tests

Added to HarnessAgentBuildServiceCacheKeyTest:

• sessionLogAgentIdIsValidForNamespacedOwnerIds — builds a session with ownerId = "namespace:default", asserts the assembled id and runs it through AgentBase.normalizeAgentId, which is the check that was failing.
• sessionLogAgentIdLeavesValidIdsUntouched — the plain owner-1 case still yields dpa-owner-1-bbb-sess_1.

Without the change the first test fails on the assembled id (dpa-namespace:default-default-..., colon still there), which is exactly what normalizeAgentId rejects in the reported log line.