Add DisableSkipErrMetrics to disable ErrSkip metrics

[ncthompson]

DisableSkipErrMetrics will skip the recoding of any SkipErr metric if enabled.
Since SkipErr results in a retry, the actual database interaction will still be recorded.

Closes #386

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.2%. Comparing base (5b7f647) to head (9e09094).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #389     +/-   ##
=======================================
+ Coverage   83.0%   83.2%   +0.1%     
=======================================
  Files         13      13             
  Lines        750     758      +8     
=======================================
+ Hits         623     631      +8     
  Misses       103     103             
  Partials      24      24             

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

[XSAM]

@ncthompson, thanks for the PR!

It looks good. I only have a naming issue. BTW, do you think skipping the entire measurement creation when encountering ErrSkip is better than recording a measurement with status OK?

[ncthompson]

@ncthompson, thanks for the PR!

It looks good. I only have a naming issue. BTW, do you think skipping the entire measurement creation when encountering ErrSkip is better than recording a measurement with status OK?

I was debating this myself when creating this. From looking at the lib itself, it always retries on a ErrSkip. So it feels like you will have "duplicate" measurements if you log both. I am open to change it if you feel like this will hide measurements that should rather be logged.

[XSAM]

@ncthompson, thanks for the PR!
It looks good. I only have a naming issue. BTW, do you think skipping the entire measurement creation when encountering ErrSkip is better than recording a measurement with status OK?

I was debating this myself when creating this. From looking at the lib itself, it always retries on a ErrSkip. So it feels like you will have "duplicate" measurements if you log both. I am open to change it if you feel like this will hide measurements that should rather be logged.

I took some time to think about this, and I prefer the way to keep the "duplicate" measurement. Here are my reasons:

• This keeps the consistent behavior of DisableErrSkip on the span part. I am concerned that having different behaviors can cause confusion to users.

  otelsql/config.go

  Lines 98 to 99 in e9f8e31

  	// DisableErrSkip, if set to true, will suppress driver.ErrSkip errors in spans.
  	DisableErrSkip bool

  otelsql/utils.go

  Lines 44 to 48 in e9f8e31

  	case driver.ErrSkip:
  	if !opts.DisableErrSkip {
  	span.RecordError(err)
  	span.SetStatus(codes.Error, "")
  	}

• The "duplicate" measurement records the actual invoke of the method even if it returned early.

• Long term fix

  • The driver should implement the latest interface from database/sql packages to prevent ErrSkip. Take https://pkg.go.dev/database/sql/driver#Execer as an example. This interface is deprecated. The driver should implement https://pkg.go.dev/database/sql/driver#ExecerContext instead.
  • If the "duplicate" measurement is really painful to users, we can deliver an additional option to skip the creation of spans and measurements later.

[ncthompson]

@ncthompson, thanks for the PR!
It looks good. I only have a naming issue. BTW, do you think skipping the entire measurement creation when encountering ErrSkip is better than recording a measurement with status OK?

I was debating this myself when creating this. From looking at the lib itself, it always retries on a ErrSkip. So it feels like you will have "duplicate" measurements if you log both. I am open to change it if you feel like this will hide measurements that should rather be logged.

I took some time to think about this, and I prefer the way to keep the "duplicate" measurement. Here are my reasons:

• This keeps the consistent behavior of DisableErrSkip on the span part. I am concerned that having different behaviors can cause confusion to users.
  

  otelsql/config.go

  Lines 98 to 99 in e9f8e31

  	// DisableErrSkip, if set to true, will suppress driver.ErrSkip errors in spans.
  	DisableErrSkip bool

  otelsql/utils.go

  Lines 44 to 48 in e9f8e31

  	case driver.ErrSkip:
  	if !opts.DisableErrSkip {
  	span.RecordError(err)
  	span.SetStatus(codes.Error, "")
  	}

• The "duplicate" measurement records the actual invoke of the method even if it returned early.

• Long term fix

  • The driver should implement the latest interface from database/sql packages to prevent ErrSkip. Take https://pkg.go.dev/database/sql/driver#Execer as an example. This interface is deprecated. The driver should implement https://pkg.go.dev/database/sql/driver#ExecerContext instead.
  • If the "duplicate" measurement is really painful to users, we can deliver an additional option to skip the creation of spans and measurements later.

Thanks for the feedback! 😄

I have updated it so it suppresses the ErrSkip like in the tracing case. Have a look if that makes sense to you.

[XSAM]

Thanks for the update and contribution. Please merge the main branch and update the CHANGELOG as suggested, so I can merge this PR.