Add new console log cache to persist log data

[jstricklin]

Initial solution to allow console log persistence across domain reloads

Due to I/O overhead and to avoid issues with deadlock related to Read/Write to file for every individual log instance, this initial approach will focus on creating snapshots of the current stored console logs in LogUtils _logEntries.

This snapshot of current logs will be created in variable intervals currently set to 2 seconds and will be stored to a text file at our Assets/Temp~/mcp-server directory. Upon domain reload, our LogUtils static class will repopulate its empty _logEntries ConcurrentQueue from the data stored in the cache when present.

We can continue to iterating on this solution as needed, but my primary concern with the original design (write to log file on every new log with rotating window) is that to count the logs stored in cache, we need to read from and write to the file on every instance of a log event - and when we reach our window limit, we are ultimately rewriting our entire file with every single transaction, incurring some potential performance overhead.

This led to testing a simple alternate solution of creating snapshots of our logs in memory in intervals, and then retrieving from the cache only upon reload.

Update also includes fix for duplicate console logs being cached in memory

[IvanMurzak]

Sorry for the merge conflict. I were needed urgently to fix a bug in the Console_GetLogs MCP tool.

[jstricklin]

@IvanMurzak I've made some changes here that should enable log snapshots to be leveraged on domain reload. We are utilizing R3 Timer instead of UnityEditor dependencies, as well as Task.Run to handle our read/write utilizing background threads.

In testing, I also noticed the recent bugfix included two subscriptions for console log handling, causing duplicate logs to be stored in memory. I removed the original subscription in favor of the Application.logMessageReceivedThreaded which should cover both instances of main/background threaded log events. Please let me know if this was intentional and I can revert this change

[IvanMurzak]

In testing, I also noticed the recent bugfix included two subscriptions for console log handling, causing duplicate logs to be stored in memory. I removed the original subscription in favor of the Application.logMessageReceivedThreaded which should cover both instances of main/background threaded log events. Please let me know if this was intentional and I can revert this change

Good point. You made it right. That was a mistake which I made in the last update. I thought the logMessageReceivedThreaded should be called when Debug.Log is called from a non main thread. That is not true. Thanks for spotting it!

Lets fix the runtime environment. This branch probably still has UnityEditor dependency in Runtime, that is why it fails non Unity Editor tests.

[Copilot]

Pull Request Overview

This PR adds a console log cache system to persist Unity log data across domain reloads. The implementation uses periodic snapshots (every 1 second) to write log data to a temporary file, avoiding I/O overhead from writing individual log entries.

Key Changes:

• Introduces a timer-based log cache system that periodically snapshots logs to disk
• Adds log restoration functionality that repopulates logs from cache on domain reload
• Updates test coverage to validate log retention behavior

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.

File	Description
LogCache.cs	New class implementing periodic log caching with file I/O operations
LogWrapper.cs	Simple serialization wrapper for log entries array
LogUtils.cs	Modified to integrate with cache system and restore logs on initialization
TestToolConsoleIntegration.cs	Added tests for log count validation and cache retention behavior

[IvanMurzak]

@jstricklin we may still lose logs in the time range in between: last save trigger and domain reload. It could be valuable logs there.

Let's utilize another trigger - OnBeforeAssemblyReload.

Startup.Editor.cs contains the event. Please add direct call of your method for triggering the save to the file. And make sure the function is capable to handle parallel calls from multiple threads.

Let's follow cascade approach where there is a single entry point (the event). Don't subscribe on that event indecently in your code. It will help us to track the event tree from one place much easier for the future maintenance. Here is the sample:

Startup.Editor.cs
├── OnApplicationUnloading
│   ├── Disconnect
│   └── LogUtils.SaveToFile() // new
├── OnApplicationQuitting
│   ├── Disconnect
│   └── LogUtils.SaveToFile() // new
├── OnBeforeAssemblyReload
│   ├── Disconnect
│   └── LogUtils.SaveToFile() // new
└── OnAfterAssemblyReload
    ├── Disconnect
    └── LogUtils.LoadFromFile() // new

[Copilot]

Pull Request Overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.

[Copilot]

Pull Request Overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 16 comments.

[Copilot]

Resource leak: finalizer calls Dispose() which may access already-disposed managed resources. The finalizer at line 145 calls Dispose(), but this is unsafe because it may try to dispose managed objects (_fileLock, _shutdownCts, timerSubscription) that could already be finalized. Consider implementing the standard Dispose pattern with a Dispose(bool disposing) method, and only dispose managed resources when disposing is true.