[GODRIVER-2931] Add a way to get txnNumber from mongo.Session Created: 02/Aug/23  Updated: 27/Oct/23  Resolved: 12/Sep/23

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

Type: Improvement Priority: Major - P3
Reporter: Tim Fogarty Assignee: Preston Vasquez
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Changes Summary:

1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output?
3. Which versions of the driver/connector does this apply to?


 Description   

Summary

In mongosync, I want to be able to log the lsid and txnNumber of a transaction so I can easily search for problematic transactions in the oplog. Currently I can get the lsid from Session.ID() but that is not enough to uniquely identify a transaction.

I was thinking something like this:

func (s *sessionImpl) TxnNumber() int64 {
     return s.clientSession.TxnNumber 
} 

And add TxnNumber() to the Session interface.

We already have Session.ID() so I think there is precedence for providing this kind of info in the public API for Session.

If we cannot get the txnNumber from the stable API, I would settle for a way to make the Go driver log it.

Motivation

Who is the affected end user?

TAR Team

How does this affect the end user?

Debugging BFs is greatly slowing our velocity. Improving our ability to debug will allow us to ship features quicker.

How likely is it that this problem or use case will occur?

Associating operations in logs with operations on the server is a common problem we face.

If the problem does occur, what are the consequences and how severe are they?

Lost time on debugging.

Is this issue urgent?

This is causing pain now so would be nice to discuss solutions soon.

Is this ticket required by a downstream team?

TAR

Is this ticket only for tests?

Just for test improvements.

Cast of Characters

Engineering Lead:
Document Author:
POCers:
Product Owner:
Program Manager:
Stakeholders:

Channels & Docs

 



 Comments   
Comment by Tim Fogarty [ 12/Sep/23 ]

Hi preston.vasquez@mongodb.com! Great! I think the CommandStartedEvent.Command would work for our use case. Thank you for the suggestion.

Since we have a way to log this, please feel free to close the ticket if you don't want to implement Session.ID().

Comment by Preston Vasquez [ 12/Sep/23 ]

Hey tim.fogarty@mongodb.com , thank you for submitting this ticket !

What is the use case for exposing the current transaction number on the stable API? Although it's deprecated, you can source the TxnNumber from mongo.XSession:

session, err := newSession(client)
if err != nil {
	panic(err)
}
 
xsession := session.(mongo.XSession)
clientSession := xsession.ClientSession()
 
fmt.Println("current txn number: ", clientSession.TxnNumber)

I understand that this is unstable API. Alternatively, you mention that:

If we cannot get the txnNumber from the stable API, I would settle for a way to make the Go driver log it.

The event monitor will include both the "lsid" and "txnNumber" in the CommandStartedEvent.Command message. For example:

{"id": {"$binary":{"base64":"LpMQKEQfTbS4PEaNRqzd0w==","subType":"04"}}} {"insert": "test","ordered": true,"lsid": {"id": {"$binary":{"base64":"LpMQKEQfTbS4PEaNRqzd0w==","subType":"04"}}},"txnNumber": {"$numberLong":"1"},"startTransaction": true,"autocommit": false,"$clusterTime": {"clusterTime": {"$timestamp":{"t":1694545352,"i":1}},"signature": {"hash": {"$binary":{"base64":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","subType":"00"}},"keyId": {"$numberLong":"0"}}},"$db": "test","documents": [{"_id": {"$oid":"6500b5c922e2d90762af0abf"},"foo": {"$numberInt":"1"}}]}

Will either of these solutions work for your team?

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