-
Notifications
You must be signed in to change notification settings - Fork 28
Conversation
Codecov Report
@@ Coverage Diff @@
## master #492 +/- ##
==========================================
+ Coverage 51.56% 53.55% +1.99%
==========================================
Files 63 63
Lines 3105 3049 -56
==========================================
+ Hits 1601 1633 +32
+ Misses 1504 1416 -88
Continue to review full report at Codecov.
|
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.
As already mentioned, really nice improvement!
I only added two questions
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.
great - I like that we can remove a lot of code by being less generic! especially in the state machine.
just spotted some undocumented types along the way, nothing major.
use of the `Traced` struct has two downsides: - Because we want to decouple the tracing logic from the application logic, we introduced generics all over the place for our code to work both with T and Traced<T>. - We currently pass the `Traced.span()` down all the services chain, but `Span`s are more of less immutable and declared in macros at compile time, so just passing this span down is useless: we cannot at any field to it. This refactoring is twofold: 1. Remove all the genericity around tracing. This resulted in a lot of simplifications, especially in the state machine, but also in the pet message services since we could get rid of the `_PetMessageHandler` trait. 2. Replace Traced<T> by a Request<T> that is going to be used everywhere. Note that we currently just use `Request` in for the PET message services and the state machine, but it should be straightforward to use anywhere else. Unlike `Traced<T>`, `Request<T>` allows us to enrich the span attached to the request: `Request::map` creates a child span a the request is mapped.
f036ceb
to
ee7a275
Compare
use of the
Traced
struct has two downsides:logic, we introduced generics all over the place for our code to
work both with T and Traced.
Traced.span()
down all the services chain, butSpan
s are more of less immutable and declared in macros at compiletime, so just passing this span down is useless: we cannot at any
field to it.
This refactoring is twofold:
Remove all the genericity around tracing. This resulted in a lot of
simplifications, especially in the state machine, but also in the
pet message services since we could get rid of the
_PetMessageHandler
trait.Replace Traced by a Request that is going to be used
everywhere. Note that we currently just use
Request
in for thePET message services and the state machine, but it should be
straightforward to use anywhere else. Unlike
Traced<T>
,Request<T>
allows us to enrich the span attached to the request:Request::map
creates a child span a the request is mapped.