Note that we already have issue 625170. So, the "just work" part is vague. The other issues I know of and not have any solutions in mind:

a. User cannot run tracing with heap profiling for days. I do not think we can do that even for tracing or just memory-infra. The trace buffer fills. But, if this is the case how do we compare memory changes between multiple days?
It can be done by trace config maybe? Do we want to tell users to do this?

b. Fix the merge_traces script. It is broken when heap profiling is turned on. The last time i tried to merge, I got dumps without browser process.

> a. User cannot run tracing with heap profiling for days. I do not think we can do that even for tracing or just memory-infra. The trace buffer fills.
1) One should be able to start tracing, set a trace config that says "dump every 3 hours" and that should work. It means: no crashes ( Issue 670828  is the key here) and no spam in the trace. Tracing v2 is a key here.
2) We should have some nicer frontend for trace config. maybe just a html page where you pick what you want to do and generates the trace config. Ideally at some point in the future that would be the same UI of the recording page of chrome://Tracing.

b> . Fix the merge_traces script. It is broken when heap profiling is turned on. The last time i tried to merge, I got dumps without browser process.
Yes we should fix this (and get test coverage) and generalize to the case of merging multiple traces.

Can we have a tracing UI with a 'Heap Dump' button? Problem with startup tracing is that it requires you to know duration of your test upfront. And without startup tracing we just take dumps at fixed 200ms intervals.

Imagine UI where after starting a trace you have 'Take a Heap Dump' button in addition to 'Stop' button, and no dumps are taken unless you click there.

Re #4 go/traceontap :)

Any update on this bug? 

We had a related  issue 700617  which would go unnoticed if it weren't for erikchen@'s investigation and long-running (~7day) traces.

Even if there's no perfect solution here, some documentation on the hacks/quirks will be helpful.

we have recently introduced third_party/catapult/tracing/bin/memory_infra_remote_dump which works via the devtools protocol, and can capture traces one off.

hjd can you (or anybody else in this thread) help with updating our docs/memory-infra and add a section: how to deal with long traces.
Still it's not a great state, because it will create one json file for each dump, but better than nothing at present state.

I just tried third_party/catapult/tracing/bin/memory_infra_remote_dump on MacOs. It is very cool! Thanks.

> Still it's not a great state, because it will create one json file for each dump, but better than nothing at present state.

Maybe I am missing something. From what I can see, the script does combine several dumps into one JSON files. Pressing "ENTER" triggers a dump. Every "ENTER" is one dump. "q" will finish the trace and combine all dumps into one json file. 

> Maybe I am missing something. From what I can see, the script does combine several dumps into one JSON files. Pressing "ENTER" triggers a dump. Every "ENTER" is one dump. "q" will finish the trace and combine all dumps into one json file. 

Ahh sorry I forgot about that feature, right. :)
My comment applies only if you get distinct traces by invoking separately memory_infra_remote_dump.