Closed SaiedKazemi closed 2 years ago
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
tracer/scamper.go | 2 | 4 | 50.0% | ||
<!-- | Total: | 18 | 20 | 90.0% | --> |
Totals | |
---|---|
Change from base Build 449: | -0.3% |
Covered Lines: | 626 |
Relevant Lines: | 646 |
internal/triggertrace/triggertrace.go, line 103 at r1 (raw file):
I like this :+1:
Yup, adding context makes it possible to easily group the lines throughout the logs that are related to the same traceroute. Super helpful for debugging.
parser/scamper1.go, line 168 at r1 (raw file):
Under what conditions does `ip.String()` return `*`? I'm not sure -- https://go.dev/play/p/YxHvwkdiWNk If this can be unit tested, all the better.
Thank you for pointing this out. I was too quick to assume ip.String()
can return "*"
. The culprit must be a few lines above hops[node.Addr] = struct{}{}
which I hadn't noticed because hops[node.Addr]
has never been "*"
in my local tests. I have added a check there and have also added a specific unit test.
tracer/scamper.go, line 145 at r1 (raw file):
Not for this PR - but it could be helpful to have metrics for events like this. At one time I hoped we could have a complete accounting of how every event received from tcpinfo passes through traceroute-caller, either "success"fully or with some specific error like this, e.g. "no-data", "command-error", etc.
I agree. In fact, I would like to revisit all event metrics traceroute-caller emits if we can prioritize and allocate time for it.
Thank you.
This change is![Reviewable](https://reviewable.io/review_button.svg)