Skip to content

Conversation

@nicolasbeauvais
Copy link
Contributor

In certain cases when using client or request SetTimeout it is possible that some trace value like dnsDone, tlsHandshakeDone or gotConn are zero, resulting in inaccurate results:

Screenshot From 2025-06-18 01-19-03
Screenshot From 2025-06-18 01-18-54
Screenshot From 2025-06-18 01-18-12

This PR add additional checks in the TraceInfo method to avoid negative values.

I'm not sure how to improve the tests for this, as aborting requests with SetTimeout will not always accurately stop the execution at the exact same point. I'm open to ideas.

Copy link
Member

@jeevatkm jeevatkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolasbeauvais Thanks for the PR. I'm sorry for the delayed response, I was occupied with my personal stuff.

I added a one review comment.

@jeevatkm jeevatkm changed the title Fix negative trace substraction when using SetTimeout fix: negative trace substraction when using SetTimeout Nov 8, 2025
@jeevatkm
Copy link
Member

jeevatkm commented Nov 8, 2025

Also, the same issue might exist in the v2 too. I will backport it afterwards, or you can also submit PR v2 if you're interested.

@nicolasbeauvais
Copy link
Contributor Author

Hey @jeevatkm, no worries, I hope you're doing good!

I've set the default value directly at object initialization, let me know if that's ok for you. I can make a PR on the v2 branch once this one is approved.

jeevatkm
jeevatkm previously approved these changes Nov 15, 2025
Copy link
Member

@jeevatkm jeevatkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolasbeauvais Thanks for updating PR.

@jeevatkm
Copy link
Member

@nicolasbeauvais It seems this test case having an issue TestTraceInfoOnTimeoutWithSetTimeout, can you please check it?

@nicolasbeauvais
Copy link
Contributor Author

@nicolasbeauvais It seems this test case having an issue TestTraceInfoOnTimeoutWithSetTimeout, can you please check it?

@jeevatkm Indeed, it seems the new test uncovered a race condition. I fixed it (at least locally), but please check the changes thoroughly I'm not an experienced Go dev ✌️

@codecov
Copy link

codecov bot commented Nov 16, 2025

Codecov Report

❌ Patch coverage is 93.10345% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 99.79%. Comparing base (66256ef) to head (d710901).
⚠️ Report is 8 commits behind head on v3.

Files with missing lines Patch % Lines
request.go 81.81% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##               v3    #1038      +/-   ##
==========================================
- Coverage   99.82%   99.79%   -0.03%     
==========================================
  Files          18       18              
  Lines        3919     3398     -521     
==========================================
- Hits         3912     3391     -521     
+ Misses          5        4       -1     
- Partials        2        3       +1     
Flag Coverage Δ
unittests 99.79% <93.10%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jeevatkm
Copy link
Member

@nicolasbeauvais Thanks for fixing the test case. It is passed now, only missing coverage on the modified code. Do you mind checking it?

Copy link
Member

@jeevatkm jeevatkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolasbeauvais Thanks for updating the PR.

@jeevatkm
Copy link
Member

Still, patch coverage is failing because of missing coverage on the same line as before. I will merge this PR. Can you please look into this coverage part later on?

@jeevatkm jeevatkm merged commit bc76a44 into go-resty:v3 Nov 18, 2025
3 of 4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug v3 For resty v3

Development

Successfully merging this pull request may close these issues.

2 participants