Adding an interop tag here because qlog generation is part of the interop listed test under L.

There is an existing qlog implementation that we could integrate.

That would make sense, I think!

Awesome find! That'll make this a lot easier.

Any news on this?

Nobody's taken it on yet.

I'll implement this eventually. qlog was instrumental for debugging and diagnosing congestion control in my (closed source) QUIC implementation.

qlog traces are MASSIVE even with gzip, which also uses a lot of CPU. You would need the ability to enable qlog on a per-connection basis, and it has to be done early so you don't drop those initial events.

I was thinking:

/// Enable logging for events that could not be associated with a connection (ex. unknown packets)
Endpoint::enable_qlog(w: AsyncWrite)

/// Enable logging for all events associated with this connection
Connecting::enable_qlog(w: AsyncWrite)

Most of the events will be emitted inside a Mutex and a a blocking filesystem write would be devastating. AsyncWrite is used mostly so the compiler would catch those.

A filter would also be cool, as most qlog events/fields are optional and some are very verbose. For example, you can emit base64 encoded packet/steam contents with the raw field, but that's extremely situational. It's not as simple as a verbosity level because the most verbose events are often unrelated.

Note qvis reportedly does not plan to implement qlog 0.4; they're sticking with 0.3 until a 1.0 RC is specced.

You would need the ability to enable qlog on a per-connection basis

I'm not sure about this. I'd imagine usually you're either spinning up an endpoint purely for testing, or don't want qlog at all.

support. very useful for interop and special uses. would love to get