Hey,
I just tried using Set-PSUCache for the first time.
The data im storing could be considered sensitive and I noticed that there's a -Roles param on this cmdlet, and a column in the database for roles (Though the roles dont show in the UI from the cache menu).
In my script I have the following command:
Set-PSUCache -Key "Keyname" -Value $Data -Persist -Role "RoleName" -Integrated
This works the first run, when the cache doesnt exist, but if I rerun my script, it fails with:
Status(StatusCode="Unknown", Detail="Exception was thrown by handler.", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1784817449.405000000","description":"Error received from peer ipv6:[::1]:58801","file":"..\..\..\src\core\lib\surface\call.cc","file_line":953,"grpc_message":"Exception was thrown by handler.","grpc_status":2}")
I've tried adding the role to the execution roles on the script (I also have the role on my account while running the script). I've tried with and without -Integrated but it's the same issue.
Removing the role entirely seems to work fine without issue.
Hello insomniacc,
Thank you for confirming that the first write succeeds, the second write fails, and that the behavior is the same with or without -Integrated. The fact that removing -Role allows the cache entry to be updated helps narrow this to the role-protected update path.
Could you please provide the following?
1. Your exact PowerShell Universal version and build.
2. The database provider in use: SQLite, SQL Server, or PostgreSQL.
3. How the script is executed, such as manually from the admin console, by a schedule, from an App, or through an API endpoint.
4. The PowerShell environment and any Run As identity configured for the script.
Could you also test with a new key, a non-sensitive value, and a test role?
Set-PSUCache -Key "RoleCacheTest" -Value "First" -Persist -Role "<TEST_ROLE>" -Integrated
Set-PSUCache -Key "RoleCacheTest" -Value "Second" -Persist -Role "<TEST_ROLE>" -Integrated
Get-PSUCache -Key "RoleCacheTest" -Integrated
Please let us know whether the final command returns "First", "Second", or also produces an error.
If possible, please include the PowerShell Universal server log entries from the same timestamp as the failed second write. We are specifically looking for the internal exception associated with the generic gRPC handler error.
Best regards,
Ruben Tapia
Sorry for the delay.
1.2026.2.3
2. SQL
3. Manually via admin console currently, but it will also be running on a schedule once i get it working.
4. Integrated. No Run As identity configured on the script, but my PSU instance runs as a service in the context of a domain service account.
I tried the example code in a new script.
I actually tested it with my administrators role which I have on my account, this should give full permissions to everything in my instance.
The output was as follows:
An exception: Grpc.Core.Internal.CoreErrorDetailException
and 'First'
1059f023-da2e-46bf-ab6f-abffb52122d0.png
Hello insomniacc,
Thank you for providing these details and for testing the simplified example. The results are very helpful, especially the confirmation that the first value remains stored after the second write fails.
We will adjust our lab environment today to match your configuration as closely as possible and attempt to reproduce the behavior. We will then review the findings with our Development team tomorrow.
We appreciate your contribution and the clear reproduction information.
Best regards,
Ruben Tapia
Hello insomniacc,
Thank you again for the detailed reproduction information.
We have now reproduced the same behavior internally using PowerShell Universal 2026.2.3 in an isolated environment.
Our control test without -Role successfully updated the persistent cache value from "First" to "Second". However, when -Role was specified, the first write succeeded and the second write failed, leaving the original value unchanged.
We also reproduced the behavior:
- With both the Administrator role and a custom test role.
- With and without -Integrated.
- With and without -Persist.
Based on these results, we are treating this as a reproducible defect in the role-protected cache update path rather than an issue specific to your SQL database or execution context.
We will review the laboratory findings and evidence with our Development team tomorrow. We will update this thread once we have their technical assessment or require any additional validation.
Thank you for your contribution and for providing a clear minimal reproduction.
Best regards,
Ruben Tapia