-
Notifications
You must be signed in to change notification settings - Fork 44
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
cleanup: remove db config #709
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall goal was to remove the old DB configs and reduce duplicate configuration code
} | ||
return | ||
return errors.Join(errA...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this deferred join still necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the internal types will superficially be different, but if we are just using Unwrap() []error
, then we still see the same slice: https://go.dev/play/p/65QFKJrpODU
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we are really just using Unwrap() []error
but I think everything is passed around via the error
interface?
this seems like the simplest way to meet that interface without implementing a new type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that there should be no difference. Are you certain this is necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you mean that we depend on always having something that implements Unwrap() []error
, then couldn't we can relax that assumption and do a conversion for the base cases of 0/1 on the other side?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update: this is the only way that works right now - doing a recursive unwrap within core does not solve the issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
revisiting in a future ticket: https://smartcontract-it.atlassian.net/browse/BCI-3330
d4bfeee
to
76ce2a8
Compare
Quality Gate failedFailed conditions |
core ref: c00f33248fe41faafaf67315d3c2665ba0656488
downstream: