Closed justinpolygon closed 1 year ago
@jbonzo, that would have saved me some time. I'll check that out.
@jbonzo, that would have saved me some time. I'll check that out.
Just gotta check that it sanitizes the info.
Hey @jbonzo, checked this out and looks like you turn it on via req.EnableTrace()
and it is mostly connection information, things like tcp connection time, dns lookup, tls connection times, etc. Here's the trace.go file, and the docs this can either be turned on at the client or request level. They do have a very nice example though. So, I replicated the formatting and incorporated the trace info from Rust.
Here's what the new output looks like after running the example script:
go run main.go
Request Info:
DNSLookup : 22.91075ms
ConnTime : 212.144542ms
TCPConnTime : 85.698167ms
TLSHandshake : 102.899167ms
ServerTime : 218.900458ms
ResponseTime : 76.948875ms
TotalTime : 507.640333ms
IsConnReused : false
IsConnWasIdle : false
ConnIdleTime : 0s
RequestAttempt: 1
RemoteAddr : 198.44.194.54:443
Request URL : GET /v2/aggs/ticker/AAPL/range/1/minute/1686614400000/1686700800000?adjusted=true&limit=50000&sort=desc
Request Headers:
Accept-Encoding: [gzip]
Authorization: [REDACTED]
User-Agent: [Polygon.io GoClient/v1.11.0]
Response Info:
Error : <nil>
Status Code: 200
Status : 200 OK
Proto : HTTP/2.0
Time : 507.640333ms
Received At: 2023-06-16 11:19:39.954729 -0700 PDT m=+0.514939459
Response Headers:
Date: [Fri, 16 Jun 2023 18:19:39 GMT]
Content-Type: [application/json]
Content-Encoding: [gzip]
Vary: [Accept-Encoding]
X-Request-Id: [48cf36ce2ab5a88e3383a97e72c596bb]
Strict-Transport-Security: [max-age=15724800; includeSubDomains]
Server: [nginx/1.19.2]
808
Gothca. Since we expose the underlying HTTP client then I think users can already access this functionality, though it might not be clear. I am fine to go ahead and merge this PR if you think your proposal is more in line with user's interest, but maybe adding to our docs that you can access the underlying HTTP client tracing could also satisfy the needs.
@jbonzo Yeah, this makes sense. Honestly, I just wanted to simplify our lives in terms of developing features for the client libraries. I added this feature on the python and js libraries and it as come in so handy when you're trying to debug what's happening behind the scenes (for example using filter params like ticker.gt, ticker.gte, ticker.lt, and ticker.lte
or when using ticker.any_of
). Having something that shows you what's happening under the hood really helped me squash these bugs and acts as a sanity check to prove you're sending the API what you think you are sending. Just being able to quickly add models.WithTrace(true)
to the request and not having you roll your own solution comes in pretty handy.
Sounds good. Ping me when you reverted back the test code and ill review again.
FYI @jbonzo -- I think we're good to go now. Thanks for your help and feedback here.
A new optional trace parameter in RequestOption enables request and response logging for debugging. When activated via
models.WithTrace(true)
on the request, the requested URL, sanitized request headers, and response headers are printed to the console.Here's an example script:
The output looks like this:
Dumping the request url, request headers, and response headers can be extremely useful for figuring out what API you're talking, the params, and what server headers are (the x-request-id is really useful for support).