Bug Report

I have a script that has the following params [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string] $asset, [Parameter(Mandatory = $false)] [string] $SNRITMNumber, [Parameter(Mandatory = $false)] [ValidateSet("Dev", "Test", "Prod")] [string] $SNEnvironment = "Prod", [Parameter(Mandatory = $false, HelpMessage = "")] [switch] $TestMode, [Parameter(Mandatory = $false, HelpMessage = "Free-form payload (object or string) forwarded from the API caller.")] [object] $Data ) When you run the job i had data in the $Data object which shows up under the job history params but when you click rerun job that data doesnt get populated [image]

## Description of Issue: Forms Authentication with Native Login fails to reload when both `-Native` and `-Domain` are configured on `Set-PSUAuthenticationMethod`. The intended configuration is to allow users to authenticate with native/domain credentials and then use the resulting group claims for role authorization. The role mapping itself is not the failing part. The failure occurs when PSU reloads `.universal/authentication.ps1`. A minimal failing configuration is: ```powershell Set-PSUAuthenticationMethod -Type "Form" -Native -Domain "ExampleDomain" ``` This also fails when a script block is included: ```powershell Set-PSUAuthenticationMethod -Type "Form" -ScriptBlock { param( [PSCredential]$Credential ) New-PSUAuthenticationResult -ErrorMessage 'Invalid credentials' } -Native -Domain "ExampleDomain" ``` Isolation results: * `Set-PSUAuthenticationMethod -Type "Form" -Native` loads successfully. * `Set-PSUAuthenticationMethod -Type "Form" -Domain "ExampleDomain"` loads successfully. * `Set-PSUAuthenticationMethod -Type "Form" -Native -Domain "ExampleDomain"` fails during reload/deserialization. * Git Sync is not required to reproduce. * A multi-node setup is not required to reproduce. * A shared SQL backend is not required to reproduce. * The same type of failure was observed after a service restart when PSU attempted to reload `authentication.ps1`. Reproduction steps: 1. Start PowerShell Universal. 2. Configure `.universal/authentication.ps1` with: ```powershell Set-PSUAuthenticationMethod -Type "Form" -Native -Domain "ExampleDomain" ``` 3. Restart PowerShell Universal or otherwise cause the repository configuration to reload. 4. Review the system logs. 5. Attempt to load the login page. Expected result: PowerShell Universal should reload the Forms Authentication Native Login configuration successfully, and the login page should remain usable. Actual result: PowerShell Universal fails to deserialize `authentication.ps1`. The login page may render in an incomplete or unusable state. Observed error: ```text Error deserializing /home/data/UniversalAutomation/Repository/.universal/authentication.ps1. Parameter set cannot be resolved using the specified named parameters. One or more parameters issued cannot be used together or an insufficient number of parameters were provided. ``` This appears to be related specifically to the `-Native -Domain` parameter combination. ## Version: Confirmed affected: * PowerShell Universal 2026.1.7, reproduced in Docker using `ironmansoftware/universal:2026.1.7-ubuntu-24.04`. * PowerShell Universal 2026.1.6, observed in an MSI Windows Service environment. ## Severity High - Bug has serious impact on usage, impacts a large number of users. ## Hosting Method? Docker Container ## Operating System? Linux ## What Database are you running? Unknown ## Is this instance licensed? Yes ## Features: * Forms Authentication * Native Login * Repository-based configuration * Role authorization using claims ## Additional Environment data: * Reproduced using Docker image: `ironmansoftware/universal:2026.1.7-ubuntu-24.04` * Git Sync was not required to reproduce. * Multi-node hosting was not required to reproduce. * Shared SQL backend was not required to reproduce. * Customer-observed environment was also affected on PSU 2026.1.6 with MSI Windows Service hosting, but the minimal reproduction was confirmed independently in Docker.

i can see the write-host in the apps console log viewer (F12), but i do not see the log entries in any of the .log files, even the endpoint write-host does not show up in the logs

Just had an app delete progress I had made after I changed the roles to allow another role to access the app. I've seen this bug in previous versions but I thought it was fixed already. Not sure if it matters but git sync is setup one way and was paused at the time. All changes were made through the PSU web interface.

# Bug Report — "Run All Tests" hangs on *Running* ; `ObjectDisposedException` in `CollectTestResultsAsync` ## Summary Running tests from the admin console ( **Automation > Tests > Run All Tests** , or a single test at `/admin/settings/.../tests/{id}` ) never completes. The UI shows the run stuck on **"Running"** indefinitely. The Pester tests themselves execute and produce results (rows appear in `TestCases` / `TestSuites` ), but the server throws an `ObjectDisposedException` while finalizing the run, so the `TestRuns` row is never marked complete ( `Status` stays `Running` , `EndTime = -infinity` ). ## Environment | | | |---|---| | PowerShell Universal | **2026.1.7** (win-x64) | | Host | Windows, `Universal.Server.exe` run on the host (developer license) — not containerized | | Database backend | PostgreSQL 16 (Docker container), `Plugins: ["PostgreSQL"]` | | Pester | 5.7.1 (bundled, resolved in the integrated runspace) | | Repo mode | file-based repository at `.\Repository` ; Git sync = PushOnly / Manual | | Test files | 3 × `*.tests.ps1` at repo root, registered in `TestFiles` (Id/Path) | ## Steps to reproduce 1. Place one or more `*.tests.ps1` (Pester 5) files in the repository and register them under Automation > Tests (rows in the `TestFiles` table). 2. Open the admin console → **Automation > Tests** . 3. Click **Run All Tests** (also reproduces with a single test run). 4. Observe the run shows **Running** and never transitions to Passed/Failed. ## Expected The run completes; `TestRuns.Status` becomes a terminal state and per-test results show in the UI. ## Actual - `TestRuns` row: `Status = Running (1)` , `EndTime = -infinity` , `Total = 0` — never finalized. - `TestCases` / `TestSuites` rows **are** written (the tests ran), confirming execution succeeds and only the *result collection / finalization* step fails. - The server logs an unhandled `ObjectDisposedException` . ## Error / stack trace ``` [ERR][PowerShellUniversal.Testing.TestService] Error executing test run. System.ObjectDisposedException: Cannot access a disposed object. Object name: 'IServiceProvider'. at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException() at PowerShellUniversal.DatabaseBase.GetTable[T]() in .../src/PowerShellUniversal/Services/DatabaseBase.cs:line 95 at PowerShellUniversal.Testing.TestService.CollectTestResultsAsync(TestRun testRun) in .../src/PowerShellUniversal.Testing/TestService.cs:line 119 at host.TestExecutionService.ExecuteTestAsync(TestRun testRun) in .../src/Host/TestExecutionService.cs:line 136 ``` ## Analysis `CollectTestResultsAsync` runs after the Pester host process finishes and tries to persist results via `DatabaseBase.GetTable[T]()` . By then the scoped `IServiceProvider` (and its `DbContext` ) has already been disposed, so the DB access throws. Because the exception is unhandled inside the test-execution continuation, the `TestRuns` record is left in the `Running` state forever (the UI polls it and shows the spinner indefinitely). This looks like a **DI scope lifetime bug** : the result-collection continuation outlives the scope it captured. It reproduces consistently on this build regardless of which/how many test files are run, and is independent of the tests' content (they pass when run directly via `Invoke-Pester` ). ## Impact The built-in Test runner is effectively unusable — every run hangs and leaves an orphaned `Running` record that must be cleared manually. ## Workarounds 1. **Run tests via a Script instead of the Test runner.** A `Invoke-Tests.ps1` script that calls `Invoke-Pester` over the same `*.tests.ps1` files completes reliably (27/27 in ~5s) and reports a pass/fail summary in the job output — it never touches `CollectTestResultsAsync` . 2. **Clear the stuck run** so the UI unsticks: ```sql DELETE FROM "TestCases" ; DELETE FROM "TestSuites" ; DELETE FROM "TestRuns" ; -- keep "TestFiles" (registration) ``` then restart the server. ## Suggested fix (for Devolutions) Resolve/scope the `DbContext` (or capture an `IServiceScopeFactory` and create a fresh scope) inside `CollectTestResultsAsync` rather than relying on the ambient scope captured when the run was started, and wrap the finalization so any failure still writes a terminal `TestRuns.Status` (e.g. `Failed` ) instead of leaving it `Running` .

When creating pages within an app, if there is already a page existing with that name PSU will overwrite the existing page code with the standard new template page. The PSU also starts to freeze at this point until the service is restarted. I believe PSU is replacing the .ps1 file in Repository\dashboards\[Appname]\pages[pagename].ps1 Where [pagename].ps1 is being replaced with a standard template. Steps to reproduce: Have an existing page with code that is different than the template. E.g: page name is Test Click "Create App Page" Enter "Test" as the name. URL can be anything After creation, PSU has replaced test.ps1 with a template. PSU is now freezing on the Pages tab of the App. Suggested resolution: -Check if .ps1 exists before replacing. -Inform user that it already exists with a dialog and ask if they want to rename or if they want to continue to replace the .ps1 file / page.

Hello, This is one of at least 2 bugs I've come across in at least the last 2 or 3 recent versions of PSU. My current, albeit tedious, workaround is to change the height for the monaco editor from 5px to something more reasonable to be able to edit the code for the App Module. The class list for this element (at least for me) is " monaco-editor no-user-select showUnused showDeprecated" Let me know if you need more information.

Prior to renewing our license, we got the "License expiring" text in the top bar as one would expect. However, even after I applied the new license file, the system says the license is still expiring. I could remove the old license, but you'd think it would say the system is licensed because it has a valid license. [image]

Hey, i want to share a temporary workaround for this issue. https://github.com/ironmansoftware/powershell-universal/issues/5481 Invoke-UDJavaScript -JavaScript "document.querySelector('.MuiDrawer-anchorBottom').remove();" or with css styling .MuiDrawer-anchorBottom { display: none; } It removes the white line at the bottom of every page when the -Theme parameter is used for New-UDApp. [image] Does anyone also see this or know why the element is there in the first place?

When setting an app in maintenance mode, the server redirects to https://server.domain.com/maintenance - which in itself is probably the intention. We don't use load balancing in front of the PSU server, so instead of using the redirection to detect maintenance, I've set up a published folder called "maintenance" with a request path of "/maintenance/" (not possible to set "/maintenance" without trailing slash). In that folder I have a default.html with information of the server being in maintenance mode. The problem here is that the redirect does not add a trailing slash, so it never shows the default document. If I add the slash, it shows. So the solution here would be to either redirect to "/maintenance/" (which would probably screw up a lot of setups) or allow to publish a folder without trailing slash. I have tried creating it both through GUI and in shell, setting default doc, etc. Or am I missing something here? Will be at PSConf.eu if anyone wants to meet up and do some PSU geeking.

https://github.com/ironmansoftware/powershell-universal/issues/5099 Description of Issue I am creating a one time schedule and then removing it, but it seems to run anyways. I am doing this in the UI and the script shows as deleted and is otherwise invisible to me. Here is a simple test scenario to reproduce. Create a script like this: $uajobid | Set-Content -path $repository\..\test.txt Set a one time schedule, delete it, and then watch it run anyways. Please fix <3 Version v4.5.5 Severity High Hosting Method MSI (Windows Service) Operating System Windows Database SQLite Licensed Yes Features No response Additional Environment data No response Screenshots/Animations No response

App Pages are empty via the VSCode extension. Via the browser or actual file, the contents are intact. Configuration sub items do not display section names and are empty and uneditable