Conversation
There was a problem hiding this comment.
Thank you! My only concern is related to the point in time that these timestamps are taken. Sometimes it is at the moment of receiving the request, sometimes just before replying. If the request processing takes very little time, I guess it does not matter, but otherwise it could potentially be confusing. How about taking the timestamp always at the beginning of the call? This way it should bring minimal boilerplate code, but keep the behaviour consistent.
|
I changed the code to address what you said. Please don't merge this after approving, I need to squash the fixup commit after. |
|
uhm... I just now noticed, that I cannot read and put timestamp at the end of the call not beginning. Sorry Should I redo it, or is this fine? |
At the end is also fine with me, as long as the behaviour is consistent. But since George is back, perhaps you can check with him. |
|
it can be merged now. I applied all fixup comments, so history is clean a george cofirmed that everything is working for him |
2 participants
I added timestamp to all gRPC calls replies which is int64 unix timestamp in milliseconds.