Skip to content

Flaky: profiler heap-dump test races the target's first allocations #202

Description

@MelbourneDeveloper

What

e2e_modules::profiler_dump_analysis_full_stack::test_profiler_object_graph_roots_inspect_and_diff_full_stack failed once on CI with:

panicked at src/sharplsp/tests/e2e_modules/profiler_dump_analysis_full_stack.rs:117:
baseline heap dump must contain StringBuilder instances (ProfileTarget allocates them constantly)

Why

start_profiler_session() starts ProfileTarget, connects the LSP client, and returns immediately — it does not wait for the target to reach its allocation loop. The test then takes the baseline heap dump straight away. If the dump lands before the loop's first iteration, there are no System.Text.StringBuilder instances on the heap and harvest_heap_address returns None.

The comment "ProfileTarget allocates them constantly" is true in steady state but not in the first moments after process start.

Fix

Retry the baseline dump a bounded number of times until the hotspot type is present, rather than assuming it already is. The assertion stays exactly as strong — if the type never appears, the test still fails with the same message — but the start-up race goes away.

Notes

Pre-existing; the test is unmodified on the cleanup branch and had passed on earlier runs of the same branch. Not filed as part of that PR to keep its scope to the restructure and the regressions it exposed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions