Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error handling w/o error slices and more #157

Closed
wants to merge 44 commits into from

Conversation

jxsl13
Copy link

@jxsl13 jxsl13 commented Aug 20, 2023

poc implementation for #155 & #117

benchmarks were broken of which only one is left broken.

Some findings that I had during my implementation is that there seem to be some Setter methods defined for value receiver methods (and some more staticcheck warnings)

And you need to dig pretty deep in order to find your configuration defaults. (http.Get for example)

Overall great test coverage which helped a lot.

Edit, just saw the other PR:
#123 seems to wrap errors already.
This PR does slightly more.
It allows to control circular reference errors at document object contruction for the top level library.

TODO:
use a tool like https://pkg.go.dev/golang.org/x/exp/cmd/gorelease to see how much the api changed.

@jxsl13 jxsl13 changed the title Poc/error handling poc/error handling w/o error slices Aug 20, 2023
@jxsl13 jxsl13 changed the title poc/error handling w/o error slices poc: error handling w/o error slices Aug 20, 2023
@jxsl13 jxsl13 changed the title poc: error handling w/o error slices poc: error handling w/o error slices and more Aug 20, 2023
@daveshanley
Copy link
Member

This will take some time to review! :)

@jxsl13
Copy link
Author

jxsl13 commented Aug 20, 2023

Another concern that I am not yet tackling neatly is how a user can easily work with those returned errors because errors.As or errors.Is would detect there to be a cyclic reference error inside of that slice but you would also need a (preferrably easy) way to check if there are also other errors inside of that multi error.

EDIT:
Maybe that MultiError (currently private type) must contain two levels of fields, one for hard errors and one for warnings

makes the user handle errors differently
the user, depending in their requirement, will either want or not want to resolve circular references.
In case that the user decides to forbid resolving circular references, they will handle returned errors as such and they will not need to pick out any specific error from the returned multi error. Changing this default removes the need to actually check if one of the errors is the circular reference error.
@jxsl13
Copy link
Author

jxsl13 commented Aug 20, 2023

  • Add dependabot

  • Update CI pipeline

  • fix many linter warnings

Allowed circular reference resolving by default

This makes the user handle errors differently.
The user, depending in their requirement, will either want or not want to resolve circular references.
In case that the user decides to forbid resolving circular references, they will handle returned errors as such and they will not need to pick out any specific error from the returned multi error.

Changing this default removes the need to actually check if one of the errors is the circular reference error.

in case a user wants to unwrap the MultiError, they should use a type assertion like this, I prefer not to bloat the public api with helper functions for error handling

doc, err := LoadDoc()
if err != nil {
    if errs, ok := err.(interface{ Unwrap() []error }); ok {
        for _, e := range errs.Unwrap() {
            fmt.Println(e)
        }
    }
}

@github-advanced-security
Copy link

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

index/find_component.go Dismissed Show resolved Hide resolved
@jxsl13
Copy link
Author

jxsl13 commented Aug 21, 2023

dunno what problems github currently has.
On a different project of mine I did not have any such problems at all.
Should rerun the action and ignore the security error, as the variable comes from filepath.Join

Tests will fail because of data races but not due to actual tests failing.

  • []error -> error
  • update and harden ci/cd pipeline
  • fix some linter warnings (staticcheck)
  • Allow circular reference resolution by default
  • consolidate some errors (global error variables)
  • improve construction of new Documents, allow library user to specify stricter api spec validation (circular references)

same PR for my forked main branch:
test results: https://github.com/jxsl13/libopenapi/actions/runs/5919537497/job/16049980816?pr=1

@jxsl13 jxsl13 changed the title poc: error handling w/o error slices and more error handling w/o error slices and more Aug 21, 2023
@daveshanley
Copy link
Member

The tests just timeout?

@jxsl13
Copy link
Author

jxsl13 commented Aug 25, 2023

the errors looked like something weird from the GitHub runner but not like the actual Go test timeout of 20 minutes was reached (which I configured).

@jxsl13
Copy link
Author

jxsl13 commented Aug 25, 2023

might be that the runner or assignment to a GitHub runner timed out

@jxsl13
Copy link
Author

jxsl13 commented Aug 26, 2023

first research indicates that high cpu load for an extended period of time might have caused the GitHub runner to have been canceled (crypto miner detection or whatever).

@jxsl13
Copy link
Author

jxsl13 commented Aug 26, 2023

seemingly splitting the tests and removing timeouts helps(?)

@daveshanley
Copy link
Member

You should remove the -race flag. It totally crashes the runner, I am assuming these runners are provisioned with a single core and can't run race tests. Also all the race conditions have been cleaned up in #162

@jxsl13
Copy link
Author

jxsl13 commented Aug 30, 2023

will merge main branch into this branch once #162 is merged into main.

@jxsl13
Copy link
Author

jxsl13 commented Sep 1, 2023

slightly confused as to why this happened:

=== RUN   TestResolver_ResolveComponents_MixedRef
    resolver_test.go:282: 
        	Error Trace:	/home/runner/work/libopenapi/libopenapi/resolver/resolver_test.go:282
        	Error:      	Not equal: 
        	            	expected: 62
        	            	actual  : 63
        	Test:       	TestResolver_ResolveComponents_MixedRef
--- FAIL: TestResolver_ResolveComponents_MixedRef (0.01s)

running this locally returned 62 again.

@codecov
Copy link

codecov bot commented Sep 2, 2023

Codecov Report

Patch coverage: 99.05% and project coverage change: -0.14% ⚠️

Comparison is base (1795bb5) 99.80% compared to head (c9cb487) 99.66%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #157      +/-   ##
==========================================
- Coverage   99.80%   99.66%   -0.14%     
==========================================
  Files         148      152       +4     
  Lines       10619    17810    +7191     
==========================================
+ Hits        10598    17750    +7152     
- Misses         21       39      +18     
- Partials        0       21      +21     
Flag Coverage Δ
unittests ?

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

Files Changed Coverage Δ
datamodel/low/v2/path_item.go 100.00% <ø> (ø)
datamodel/low/v3/path_item.go 96.86% <ø> (-1.78%) ⬇️
what-changed/model/components.go 100.00% <ø> (ø)
what-changed/model/path_item.go 100.00% <ø> (ø)
document.go 96.44% <96.73%> (-1.70%) ⬇️
index/find_component.go 99.18% <99.17%> (-0.38%) ⬇️
datamodel/high/base/schema.go 100.00% <100.00%> (ø)
datamodel/high/node_builder.go 97.78% <100.00%> (-1.00%) ⬇️
datamodel/high/v3/components.go 100.00% <100.00%> (ø)
datamodel/low/reference.go 97.14% <100.00%> (-0.71%) ⬇️
... and 10 more

... and 132 files with indirect coverage changes

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

@jxsl13
Copy link
Author

jxsl13 commented Oct 11, 2023

should be used as reference, errorutils might be replaced with simply errors.Join

@jxsl13 jxsl13 closed this Nov 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants