Skip to content

[tests] Read FastTiming dump from file - #12492

Open
simonrozsival wants to merge 2 commits into
mainfrom
dev/simonrozsival/fix-fast-timing-flake
Open

[tests] Read FastTiming dump from file#12492
simonrozsival wants to merge 2 commits into
mainfrom
dev/simonrozsival/fix-fast-timing-flake

Conversation

@simonrozsival

Copy link
Copy Markdown
Member

Summary

  • configure the existing FastTiming file output for ConcurrentEventsCanGrowAndDump
  • read the completed dump from the app cache with run-as instead of waiting for thousands of events through logcat
  • restore both debug.mono.log and debug.mono.timing after the test

The test still verifies concurrent storage growth through the 4096 to 8192 log message and verifies complete traversal through the final [2/8] Assembly decompression aggregate in the file.

Validation

  • make prepare && make all
  • built MSBuildDeviceIntegration.csproj in Debug
  • reproduced the original logcat assertion in 8/10 runs on an API 36 arm64 emulator
  • file-backed version passed 25/25 consecutive runs on the same emulator

Fixes #12491

Avoid relying on logcat to transport thousands of timing events before the dump completion marker. Configure the existing file output, read it through run-as, and restore both debug properties after the test.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 8de803be-c212-4d54-8309-da5e339f193c
Copilot AI lite review requested due to automatic review settings August 24, 2026 12:43

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the FastTimingTests.ConcurrentEventsCanGrowAndDump device test to validate FastTiming dump completion via a file in the app’s cache directory (read with run-as), avoiding flaky logcat truncation when thousands of timing events are emitted.

Changes:

  • Configure FastTiming to write dump output to a cache-backed file via debug.mono.timing (to-file,filename=...).
  • Trigger the dump via broadcast, then read the resulting file with adb exec-out run-as ... cat ... and assert the completion marker is present.
  • Preserve and restore both debug.mono.log and debug.mono.timing system properties after the test.
Show a summary per file
File Description
tests/MSBuildDeviceIntegration/Tests/FastTimingTests.cs Switches dump verification from logcat monitoring to reading a file from app cache via run-as, and restores timing-related system properties after the test.

Review details

  • Files reviewed: 1/1 changed files
  • Comments generated: 1
  • Review effort level: Lite

);

Assert.IsTrue (dumpCompleted, $"Output did not contain {dumpCompletedMessage}.");
string timingOutput = RunAdbCommand ($"exec-out run-as {proj.PackageName} cat cache/{timingFileName}");
Remove the generated timing dump in the test cleanup path so it does not remain in the application cache after either a passing or failing run.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 8de803be-c212-4d54-8309-da5e339f193c
@simonrozsival

Copy link
Copy Markdown
Member Author

Final local validation on API 36 arm64:

  • file-backed test passed 50/50 consecutive stress runs across two fresh emulator sessions
  • original logcat-based assertion failed 8/10 runs on the same setup
  • final cleanup version passed after rebuild
  • command output confirms cache/fast-timing.txt is removed from the finally path

Cleanup is included in commit 78f7601aa.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[flaky test] FastTimingTests.ConcurrentEventsCanGrowAndDump loses dump completion marker in logcat

2 participants