Reported via: declarative-sdk-for-k v0.4.2 retry+CapabilityError fallback
Upstream: This report is filed on the public Keeper-Security/Commander repository intentionally. No protobuf bytes, base64, or tenant-identifying material appears in this issue body.
Title
pam rotation edit: router set_record_rotation returns 500 after pamEnvironment apply (Commander 18.x)
Summary
After declaratively creating pamConfiguration + pamMachine + nested pamUser, post-apply pam rotation edit returns 500 Internal server error (KeeperApiError on set_record_rotation). Reproduced on two runs with fresh records.
Environment
- Commander 18.0.0.
- Enterprise lab tenant; nested
resources[].users[] rotation (pam-environment.v1).
Repro (high level)
- Apply minimal pam-environment manifest creating pamConfiguration, pamMachine, pamUser under
resources[].users[] with rotation_settings tied to parent resource.
- Apply invokes
keeper pam rotation edit with --record, --resource, --config, profile general, schedule flags, --force.
- Commander POSTs protobuf to
/api/user/set_record_rotation.
- Observed:
Set rotation error "500": Internal server error.
Expected
Rotation registers or returns non-500 validation error.
Notes
- v17.2.16..v18.0.0
discoveryrotation.py diff: pam rotation info JSON only; not rotation edit submit path.
Privacy
No UIDs/tenant IDs in public GH body; attach internally.
G8 update — 2026-05-05
Probes
- 3 schedule-shape variants tested: lone
ON_DEMAND payload | [] | '' — all 500.
- Reran on 18.0.0 same tenant + nested pamUser: same 500.
- Cross-version replay on 17.2.16 not possible (DSK >=18 floor); standalone 17.2.16 Commander CLI repro recommended for upstream triage.
Protobuf payload available privately on request via Keeper support channel.
Recommended upstream action
Inspect Keeper router log for set_record_rotation 500 stacktrace on tenant <enterprise tenant on Keeper Cloud> between timestamps in attached evidence. Likely missing-required-field on backend if 17.2.16 standalone CLI also fails on current backend.
Reported via: declarative-sdk-for-k v0.4.2 retry+CapabilityError fallback
Upstream: This report is filed on the public
Keeper-Security/Commanderrepository intentionally. No protobuf bytes, base64, or tenant-identifying material appears in this issue body.Title
pam rotation edit: router set_record_rotation returns 500 after pamEnvironment apply (Commander 18.x)
Summary
After declaratively creating pamConfiguration + pamMachine + nested pamUser, post-apply
pam rotation editreturns 500 Internal server error (KeeperApiErroronset_record_rotation). Reproduced on two runs with fresh records.Environment
resources[].users[]rotation (pam-environment.v1).Repro (high level)
resources[].users[]with rotation_settings tied to parent resource.keeper pam rotation editwith--record,--resource,--config, profilegeneral, schedule flags,--force./api/user/set_record_rotation.Set rotation error "500": Internal server error.Expected
Rotation registers or returns non-500 validation error.
Notes
discoveryrotation.pydiff:pam rotation infoJSON only; notrotation editsubmit path.Privacy
No UIDs/tenant IDs in public GH body; attach internally.
G8 update — 2026-05-05
Probes
ON_DEMANDpayload |[]|''— all 500.Protobuf payload available privately on request via Keeper support channel.
Recommended upstream action
Inspect Keeper router log for
set_record_rotation500 stacktrace on tenant<enterprise tenant on Keeper Cloud>between timestamps in attached evidence. Likely missing-required-field on backend if 17.2.16 standalone CLI also fails on current backend.