Devolutions/UniGetUI · warning · TimeoutException

Task {taskName} for manager {Name} did not finish after {Pac

Error message

Task {taskName} for manager {Name} did not finish after {PackageListingTaskTimeout} seconds, aborting.  You may disable timeouts from UniGetUI Advanced Settings

What it means

PackageManager.RunListingTaskWithTimeout is the generic timeout guard for every package-listing task (FindPackages, GetAvailableUpdates, GetInstalledPackages). It runs the manager's *_Unsafe method on a background Task, kills any registered listing subprocesses via KillListingProcesses on expiry, finalizes the dangerous task, and throws TimeoutException with the given taskName. PackageListingTaskTimeout is a hard 60 s. The three public callers catch the exception, unwrap AggregateException, and either retry once via AttemptFastRepair() (when RetryListingTasksOnTimeout is true, the default) or return an empty list on the second attempt. Chocolatey overrides RetryListingTasksOnTimeout to false, so it surfaces as an immediate empty result.

Source

Thrown at src/UniGetUI.PackageEngine.PackageManagerClasses/Manager/PackageManager.cs:315

                }
        }

        private T RunListingTaskWithTimeout<T>(Func<T> method, string taskName)
        {
            List<Process> processes = [];
            var task = Task.Run(() =>
            {
                _listingProcesses.Value = processes;
                return method();
            });

            if (!task.Wait(TimeSpan.FromSeconds(PackageListingTaskTimeout)))
            {
                if (!Settings.Get(Settings.K.DisableTimeoutOnPackageListingTasks))
                {
                    KillListingProcesses(processes);
                    CoreTools.FinalizeDangerousTask(task);
                    throw new TimeoutException(
                        $"Task {taskName} for manager {Name} did not finish after "
                            + $"{PackageListingTaskTimeout} seconds, aborting.  You may disable "
                            + $"timeouts from UniGetUI Advanced Settings"
                    );
                }

                task.Wait();
            }

            return task.GetAwaiter().GetResult();
        }

        /// <summary>
        /// Returns an array of Package objects that the manager lists for the given query. Depending on the manager, the list may
        /// also include similar results. This method is fail-safe and will return an empty array if an error occurs.
        /// </summary>
        public IReadOnlyList<IPackage> FindPackages(string query) => _findPackages(query, false);

View on GitHub (pinned to 9b1d7d0eab)

Solutions

Enable 'Disable timeouts on package listing tasks' (Settings.K.DisableTimeoutOnPackageListingTasks) in Advanced Settings if listing legitimately takes longer than 60 s.
Run the equivalent CLI manually and time it (e.g. `winget list`, `winget upgrade`, `scoop export`, `choco outdated`) to isolate whether the manager or UniGetUI is the bottleneck.
For Chocolatey specifically, note RetryListingTasksOnTimeout is false — a single timeout yields empty results, so stabilizing the environment (network/proxy/UAC) matters more than for other managers.
If you control the manager integration, override RetryListingTasksOnTimeout => true and RegisterListingProcess(...) so KillListingProcesses can actually terminate hung children on timeout.
Check UniGetUI logs for the TimeoutException line and the preceding AttemptFastRepair warning to see whether the single retry already occurred.

Defensive patterns

Strategy: retry

Validate before calling

// Cheap pre-checks before invoking a listing API that would burn a 60s slot.
if (!manager.IsReady())
    return Array.Empty<IPackage>();

if (!Settings.Get(Settings.K.DisableTimeoutOnPackageListingTasks)
     && !await NetworkIsAvailableAsync()
     && queryRequiresNetwork(manager))
{
    return Array.Empty<IPackage>();
}

Try / catch

// Public APIs (FindPackages/GetInstalledPackages/GetAvailableUpdates) are
// fail-safe and return [] on timeout after one AttemptFastRepair retry.
// If you call RunListingTaskWithTimeout directly (protected/derived), wrap it:
try
{
    var packages = RunListingTaskWithTimeout(() => GetInstalledPackages_UnSafe(), "_getInstalledPackages");
}
catch (TimeoutException ex) when (!Settings.Get(Settings.K.DisableTimeoutOnPackageListingTasks))
{
    Logger.Warn($"Listing timed out for {Name}: {ex.Message}");
    return Array.Empty<IPackage>();
}

Prevention

Rely on the fail-safe public APIs; they retry once via AttemptFastRepair and return [] rather than throwing.
Remember Chocolatey (RetryListingTasksOnTimeout == false) does NOT retry — stabilize its environment.
Call RegisterListingProcess in any *_Unsafe override so KillListingProcesses can actually terminate hung children on timeout.
Set DisableTimeoutOnPackageListingTasks only when listing legitimately exceeds 60 s; otherwise it converts a hung manager into an indefinite UI freeze.

When it happens

Trigger: Any of FindPackages(query), GetAvailableUpdates(), or GetInstalledPackages() whose *_Unsafe implementation spawns a manager CLI that does not finish within 60 s while Settings.K.DisableTimeoutOnPackageListingTasks is OFF. Concretely the timeout path fires inside RunListingTaskWithTimeout at line 315; the taskName is one of '_findPackages', '_getAvailableUpdates', '_getInstalledPackages'.

Common situations: WinGet/Scoop/Choco index refresh stalling on a metered or proxied network; a listing subprocess stuck on a UAC/elevation prompt; GetAvailableUpdates hitting a fresh `RefreshPackageIndexes` whose own 60 s Wait (line 390-391) already elapsed; very large installed-package sets on slow disks; antivirus injecting latency. Chocolatey specifically will not retry, so a single slow run yields empty results.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of Devolutions/UniGetUI@9b1d7d0eab (2026-08-13). Data as JSON: /api/errors/577a970149a3609e. Report an issue: GitHub.