-
Notifications
You must be signed in to change notification settings - Fork 0
Refactor to clean up code, better tests, add transaction ID support #4
Conversation
#### `fatalf(format, ...args)` | ||
|
||
### `transactionLogger` | ||
Get a logger that adds a `transaction_id` property to the meta. Useful for tracking related requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be the same logger as the other logger and just allow the other logger to accept an optional transaction id? That would make it such that we could just in places we use the same logger everywhere and just add in this parameter in order to make the transaction switch a bit easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but then we run into race conditions if we have code executing in parallel. Imagine this situation:
- Execute concurrent transactions using
Promise.all
- In one, set the transaction ID
- If it's a shared instance, then the other chain would get that transaction ID, or overwrite it when it tries to set it for itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other option is providing the transaction ID to every call to log
, info
, debug
, etc, but that would be tedious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I see what you mean, sort of.
It would be nice to have our services such that on original invocation of the service, set up the logger with the transaction id as a synchronous process, then later whatever operations it does use that logger that has the transaction id already set up (either created or received via parameter). This shouldn't be too hard given that our services use api endpoints as their entry points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah exactly. I'd like to instantiate a logger using getTransactionLogger
on each request and wrap the request in an object that can do like this.log
. So this is to help us get towards that.
Looks good. I think having the transactionLogger be separate from the regular logger is less preferable than adding to logger, the ability to take an optional parameter. |
This refactor does a few things: