Confirming the issue as this is a feature request. Waiting for more inputs on this

Hey Antonin, thanks for the proposal. 

I believe this is the same-ish situation as https://bugs.chromium.org/p/chromium/issues/detail?id=332624

So far we haven't made headway in this area. And there was some discussion about using https://domenic.github.io/zones/ for this. Curious if zones would be a good primitive to build this on. What do you think?

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for your response, Paul.

Just studied the document briefly, it pretty much looks like zones from Angular2[1]. Zones are about attaching state to an async task in a way that this state is auto-magically inherited/shared by child/chained async tasks potentially spawned in the process. In essence a logical chain of async tasks can share a context called "zone". The problem I'm trying to solve here is not about state book-keeping but about long stack traces caused by long chains of async tasks. I have just created an experimental change[2] to DevTools code to allow longer async tasks stack traces. Please look at the first screenshot[3] and the second screenshot[4] where you can see that just a simple loop of 20 iterations generated a huge stack trace (I couldn't even take complete screenshot of it). Why is that? core.async state machine looks at the code given (the go-loop at line #16), identifies all async operations (the timeout call at line #20), breaks the code into pieces on async call boundaries and then wraps those into anonymous functions as "jobs". Each job is wrapped in some glue code which stores and restores the machine state (essentially this is a subset of zones functionality). Jobs are then chained as normal async calls via goog.async.nextTick. Please note that goog.async.nextTick is aggressive (for a reason), so the jobs chain is partitioned to short strings of jobs which are interleaved with setTimeout calls to not starve javascript scheduler. In total my simple loop with 20 iterations generated a chain of 40+ async jobs (20 promises and 20 setTimeouts). But essential is only the stack trace before entering the loop (break-loop-async) and last loop iteration (stack traces of last 3 chained async tasks on the second screenshot). Please don't judge the number of stack frames generated by core.async. I believe it could be optimized to be more readable in debuggers, but I assume that wasn't the goal when it was implemented. It can be solved by black-boxing. Our main issue here is the large number of chained async tasks.

My proposal is about detection of loops of async calls (which lead to long chains of async tasks). 
A library or user code which is aware of "looping" constructs could optionally signal each new loop iteration boundary and DevTools could drop recorded stack trace frames in V8DebuggerAgentImpl.

Please note that my proposal for new API in V8DebuggerAgentImpl is not essential to achieve my goal here. It is just an optimization. In Dirac I can increase DevTools limit (maxAsyncStackChainDepth) and implement the stack trace frames dropping on DevTools side. But this solution is fragile because without this support any long-running loop will eventually hit the limits.

As a side note. Zones could be used to implement stack-traces completely in user-land as a library without DevTools cooperation. Angular guys have done that[5] as a major show-case for zone.js. But I don't want to go this route. I strongly believe DevTools should do this job, I don't want to force people to use some kind of framework to provide reasonable async stack traces for them. DevTools has best tools to do that consistently and is already almost there.

[1] https://github.com/angular/zone.js
[2] https://github.com/binaryage/dirac/commit/be3ef5cce91a0c4b9f3f02327633353f16948a3c
[3] https://dl.dropboxusercontent.com/u/559047/core-async-loop-1.png
[4] https://dl.dropboxusercontent.com/u/559047/core-async-loop-2.png
[5] https://github.com/angular/zone.js/blob/master/lib/zone-spec/long-stack-trace.ts

We reworked our async stacks and supported cross target stacks. It means that universal detecting loops and collapsing can be implemented only on frontend side. We can detect loops for each target as well but this work is subset of general call stack sidebar improvement.