Summary
When using infra.aap_configuration.controller_roles to add a user to a team with role: member (lowercase), the run fails with a terse error:
Task failed: Module failed: 'detail'
This happens even though the role value is valid and lowercase. The error message is not actionable and hides the underlying Controller API response, making it difficult to understand whether the issue is object lookup, org scope, or role mapping.
Environment
AAP / Controller: 2.5.x
Collection: infra.aap_configuration (v4.x)
Execution: via infra.aap_configuration.dispatch
Auth: Controller username/password
OS/Python: UBI9 / Python 3.12
Variables / Snippet
controller_roles: - { user: "skowalcz", target_team: "dwp", role: "member" }
skowalcz (user) exists.
dwp (team) exists (under the expected organization).
Other similar role grants in the same run succeed.
Steps to Reproduce
Ensure the user (skowalcz) and team (dwp) exist in the intended organization.
Apply the controller_roles snippet above.
Execute the playbook that runs infra.aap_configuration.dispatch.
Actual Behavior
The dispatch role surfaces a non-descriptive error:
[ERROR]: Task failed: Action failed: ['Errors encountered applying configurations:',
{'controller_roles_errors': [
{'ERROR_MESSAGE': "Task failed: Module failed: 'detail'", 'role': 'member', 'user': 'skowalcz'}
]}]
fatal: [localhost]: FAILED! => {
"msg": [
"Errors encountered applying configurations:",
{
"controller_roles_errors": [
{
"ERROR_MESSAGE": "Task failed: Module failed: 'detail'",
"role": "member",
"user": "skowalcz"
}
]
}
]
}
Expected Behavior
If the operation is valid (assign “member” to a team), the assignment should succeed.
If the operation is invalid (e.g., wrong org scope, team not found, or “member” not assignable via this path), the role should surface the full Controller API error payload (status code + detail body) so users can understand and remediate.
In all cases, the top-level error should be actionable (which object is missing, which role/content-type mismatch, org mismatch, etc.).
Notes / Observations
The same pattern succeeds for another user (a superuser). That may be masking a deeper issue, but regardless, the generic 'detail' message prevents identifying the true cause.
Using controller_teams with a users: list successfully adds team membership, so the underlying objects exist and are reachable. The problem here is the opaque error when using controller_roles.
Request
Improve error surfacing in controller_roles (and/or dispatch) so the full Controller API response is included in the failure (status code, message, and relevant fields).
Optionally, add validation and clearer messages when attempting a team membership action via controller_roles (if that pathway is not intended), e.g., “Team membership must be managed via controller_teams.users, not controller_roles.”
Artifacts
Happy to provide sanitized -vvv task output and (if needed) the Controller API response body from the failing request.
Thanks!
Summary
When using infra.aap_configuration.controller_roles to add a user to a team with role: member (lowercase), the run fails with a terse error:
Task failed: Module failed: 'detail'
This happens even though the role value is valid and lowercase. The error message is not actionable and hides the underlying Controller API response, making it difficult to understand whether the issue is object lookup, org scope, or role mapping.
Environment
AAP / Controller: 2.5.x
Collection: infra.aap_configuration (v4.x)
Execution: via infra.aap_configuration.dispatch
Auth: Controller username/password
OS/Python: UBI9 / Python 3.12
Variables / Snippet
controller_roles: - { user: "skowalcz", target_team: "dwp", role: "member" }skowalcz (user) exists.
dwp (team) exists (under the expected organization).
Other similar role grants in the same run succeed.
Steps to Reproduce
Ensure the user (skowalcz) and team (dwp) exist in the intended organization.
Apply the controller_roles snippet above.
Execute the playbook that runs infra.aap_configuration.dispatch.
Actual Behavior
The dispatch role surfaces a non-descriptive error:
[ERROR]: Task failed: Action failed: ['Errors encountered applying configurations:',
{'controller_roles_errors': [
{'ERROR_MESSAGE': "Task failed: Module failed: 'detail'", 'role': 'member', 'user': 'skowalcz'}
]}]
fatal: [localhost]: FAILED! => {
"msg": [
"Errors encountered applying configurations:",
{
"controller_roles_errors": [
{
"ERROR_MESSAGE": "Task failed: Module failed: 'detail'",
"role": "member",
"user": "skowalcz"
}
]
}
]
}
Expected Behavior
If the operation is valid (assign “member” to a team), the assignment should succeed.
If the operation is invalid (e.g., wrong org scope, team not found, or “member” not assignable via this path), the role should surface the full Controller API error payload (status code + detail body) so users can understand and remediate.
In all cases, the top-level error should be actionable (which object is missing, which role/content-type mismatch, org mismatch, etc.).
Notes / Observations
The same pattern succeeds for another user (a superuser). That may be masking a deeper issue, but regardless, the generic 'detail' message prevents identifying the true cause.
Using controller_teams with a users: list successfully adds team membership, so the underlying objects exist and are reachable. The problem here is the opaque error when using controller_roles.
Request
Improve error surfacing in controller_roles (and/or dispatch) so the full Controller API response is included in the failure (status code, message, and relevant fields).
Optionally, add validation and clearer messages when attempting a team membership action via controller_roles (if that pathway is not intended), e.g., “Team membership must be managed via controller_teams.users, not controller_roles.”
Artifacts
Happy to provide sanitized -vvv task output and (if needed) the Controller API response body from the failing request.
Thanks!