stats: add BeginTime to stats.End

[btc]

This change allows stats.Handler implementations easily determine duration.

[thelinuxfoundation]

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.

After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

• User @btc isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

[btc]

I completed the CLA form.

[btc]

Note that end time was not being set here.

[dfawley]

Thanks for the PR.

I'm fine with this change, but with the caveat that this API is experimental and will be redesigned in the somewhat-near future. There is a fundamental problem with this stats API and the capabilities of replay. I plan to address this in a gRFC at some point in the future.

In a revamp, I don't intend to pass either begin or end time, since those are literally time.Now() right before the stats handler is called; the stats handler can keep track of time on its own instead, if needed.

[btc]

Are there preliminary comments about the "capabilities of replay" you mention?

[dfawley]

Are there preliminary comments about the "capabilities of replay" you mention?

Sorry, I meant to say "retry", but it's specifically the replaying of messages that are a problem. The gRFC for retry is here for reference. The issue with stats is that we include the message payload in the call to the stats handler, but the payload is no longer owned by gRPC after the Send() call that contains it returns. However, we may need to retransmit that message on subsequent retry attempts.

Generally, though, the stats API wasn't designed with retry in mind. E.g. there is no distinction between an RPC call being performed by the application and individual attempts being sent on the wire.

[btc]

Got it. That's fairly problematic. Thanks for letting me know.