[BUG] Daemon memory grows into gigabytes: OperationHistory.json stores multi-MB output lines and is fully loaded and kept resident

Open
  • Is something wrong?
#5,703 0 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend, performance

Research direction

Start by locating OperationHistoryRecord.MaxOutputLines and OperationHistoryStore.LoadUnlocked(); the issue identifies the oversized output line and full-store load as the memory growth path. Read the existing output-cap tests and trace how records are clamped on load and save. Done means individual lines and total record output are bounded, existing bloated history shrinks on save, and the tests work across languages.

Written by the indexing model from the issue text.

Description

bug
Please confirm these before moving forward
  • I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
  • I have tested that this issue has not been fixed in the latest (beta or stable) release — the current main branch (e857b3f) still has OperationHistoryRecord.MaxOutputLines capping the number of output lines, not their size.
  • I have checked the FAQ section for solutions.
  • This issue is about a bug.
UniGetUI Version

2026.3.3 (Windows installer, x64)

Windows version, edition, and architecture

Windows 11, build 10.0.26200, x64

Describe your issue

The UniGetUI daemon (UniGetUI.exe --daemon, autostarted at login, only running the hourly automatic-update cycle) sits at ~3.4 GB working set / ~5.6 GB private bytes and never releases it. Task Manager can show a much smaller number after Windows trims the working set (I observed it dropping to single-digit MB at an hourly maintenance tick), but the commit charge stays — the memory is genuinely held.

Root cause chain (measured on my machine):

  1. A Chocolatey auto-update of visualstudio2026buildtools failed 25 consecutive times between 2026-10-28 and 2026-10-29 (one attempt per hourly automatic-update cycle).
  2. In each failure, the PowerShell error output echoed the whole offending payload into a single line:
    ERROR: Exception calling "DeserializeObject" with "1" argument(s): "Unterminated string..."
    producing 25 lines × ~24.5 MB each.
  3. OperationHistoryRecord.MaxOutputLines = 5000 limits the line count only, so every one of those 24.5 MB lines is persisted verbatim. OperationHistory.json grew to 615 MB: 568 records, where the 25 giant lines account for ~613 MB, and the median size of the remaining 543 records is 133 bytes.
  4. The next recorded operation makes OperationHistoryStore.LoadUnlocked() do File.ReadAllText (≈ 1.2 GB as UTF-16) plus JsonSerializer.Deserialize into a static in-memory cache that lives for the daemon's lifetime → ~3.4 GB working set / ~5.6 GB commit.
  5. Every subsequent operation re-serializes the whole store and rewrites the 615 MB file (O(store) disk write per operation).
Steps to reproduce the issue

Not strictly reproducible on demand, but the chain is: let an automatic update of a package fail in a way whose install script echoes a large payload into one output line (Chocolatey + a PowerShell DeserializeObject exception did this here), let it repeat over several automatic-update cycles, then let UniGetUI record one more operation → the daemon reads the whole store into its static cache and keeps it.

UniGetUI Log

Application logging was not enabled on this machine, so no log files are available. The evidence above comes from the on-disk state (%LOCALAPPDATA%\UniGetUI\Configuration\OperationHistory.json) and from process measurements (Get-Process working set / private bytes), both captured while reproducing the analysis.

Package Managers Logs

Not captured (logging was disabled). The offending captured output is preserved inside the history file itself; the first characters of each giant line are shown in "Describe your issue" above. I did not paste them in full (24.5 MB each).

Relevant information

Proposed fix (I have it ready as a patch and can submit a PR if maintainers agree with the direction):

  • Cap a single stored line's characters (keep both ends around a visible truncation marker) and cap the total stored characters per record (keep the tail, where results/errors live) — i.e. byte-level bounds complementing the existing line-count bound.
  • Clamp on load and on save, so stores already bloated by older versions shrink back on the next save instead of staying resident in memory and on disk.
  • The same patch makes the existing output-cap test assertions language-neutral: CoreTools.Translate returns localized markers, so Assert.Contains("omitted", ...) fails on machines running UniGetUI in a non-English language (verified on a zh-language machine, both before and after the change).
Dominant language
C#
Stars
26.8k
Forks
970
Avg merge
17h 39m
Merged PRs (30d)
132

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Devolutions/UniGetUI

All issues in Devolutions/UniGetUI

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.