[GODRIVER-2172] Include context in Command Events Created: 04/Oct/21  Updated: 27/Oct/23  Resolved: 11/Oct/21

Status: Closed
Project: Go Driver
Component/s: Monitoring
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: James Hartig Assignee: Benji Rewis (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Changes: Not Needed

 Description   

It would be useful to include the context.Context in the CommandStartedEvent and CommandFinishedEvent structs so extra application contextual information can be included in metrics. Things such as the calling function or the source of the query would be great to include in our metrics but right now there's no way to connect these events to their original function calls. If the context was passed along then a value could be added to the context and then retrieved later from the event.

I would be willing to contribute these changes if this is an acceptable feature. I would add a `Ctx context.context` field to `CommandStartedEvent` and `CommandFinishedEvent`.



 Comments   
Comment by Benji Rewis (Inactive) [ 11/Oct/21 ]

Sounds good! Feel free to reopen this ticket if anything changes.

Comment by James Hartig [ 11/Oct/21 ]

We were already using those but I wasn't aware that the context was the same as the one passed to the command. It makes sense thinking about it now but I assumed the monitors were some sort of asynchronous callback that happened out-of-band. It does seem like that will work so I think this can be closed. I appreciate the help!

Comment by Benji Rewis (Inactive) [ 11/Oct/21 ]

Got it, that makes sense! I'm curious if you could just use the Started, Succeeded and Failed callbacks defined on a CommandMonitor to access the context of the published event. Is there a reason you need the context stored on the actual command struct?

Comment by James Hartig [ 08/Oct/21 ]

Hey Benji Rewis,

It depends on the application, it could be as simple as a line number or function name that originated the query or it could be a userID. With our other drivers we have a map that we store in the context and then when we publish metrics as a part of that query we include that map as labels on the metric. I like that the Mongo driver publishes events but the events happening out-of-band lose the ability to get this information without being able to store it somehow. I only suggested the context because it's already being plumbed through all of the code but if there was another way to store key-value pairs and have them passed along, that would be acceptable too.

Thanks!

Comment by Benji Rewis (Inactive) [ 08/Oct/21 ]

Hello again, james@getadmiral.com!

The structure of both CommandStartedEvent and CommandFinishedEvent are defined by our cross-drivers specification on command monitoring. So, normally, adding a field to either struct would probably require a cross-driver’s change.

contexts, however, are unique to Go, and so a cross-drivers change does not make sense. While it doesn’t seem too tough to add the underlying context to published events, I’d love to hear a little more about your use-case.

Things such as the calling function or the source of the query

Are you referring to the function from your own application that is calling the Go driver API? I.e. are you trying to track which section of your own code is producing a particular event in the driver?

And, what information would you be adding to the context? A unique "function caller" token?

Comment by Benji Rewis (Inactive) [ 05/Oct/21 ]

Hello james@getadmiral.com and thanks for your improvement suggestion! We're taking a look now.

Generated at Thu Feb 08 08:37:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.