Properly use LoggingContext in Participant Server
See original GitHub issueThere are quite a few classes where we pass the LoggingContext
to the constructor, instead of the individual methods.
This means that the log lines of the methods will use the logging context that was used during initialization. The result is that call-specific information (e.g. party, beginOffset, endOffset, …) are not actually logged.
Basically, the logging context needs to be passed along the chain from where the request is received to where the data for the request is fetched.
Example chain:
ApiTransactionService#getTransactions
-> IndexTransactionService#transactions
(impl: LedgerBackedIndexService
)
-> ReadOnlyLedger#flatTransactions
(impl: BaseLedger
)
-> TransactionsReader#getFlatTransactions
Examples of where the wrong logging context (from the class’ constructor) is being used:
This pattern is quite pervasive throughout the code base and requires adding an implicit logging context to the methods of internal interfaces (e.g. Index*Service
, LedgerDao
, Ledger
, …)
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (9 by maintainers)
Sorry, I didn’t try to argue “against” you, but simply that either we use the approach properly, or just don’t bother with it. It’s the middle ground that doesn’t provide much benefit. 👍
Note that passing down the logging context to services via constructors is helpful: the logging context created when instantiating the service handler contains (at the very least) the participant identifier. Instead of creating a brand new logging context this information can be enriched by individual endpoints.