Repository navigation
Add remote capability dedupe against local capabilities - #23932
amit-momin wants to merge 8 commits into
Conversation
|
✅ No conflicts with other open PRs targeting |
|
I see you updated files related to
|
ilija42
left a comment
ilija42
left a comment
There was a problem hiding this comment.
this approach would still take down the chain cap though?
| // Prefer capabilities hosted locally over remote ones. If this node serves a capability ID as | ||
| // part of a capability DON, never set up a remote shim for the same ID. This is a safety mechanism | ||
| // to prevent duplicate capability configs taking down the capability altogether. | ||
| remoteCapabilityDONs = filterLocalCapabilitiesFromRemote(remoteCapabilityDONs, myCapabilityDONs) |
There was a problem hiding this comment.
@amit-momin Is it possible for the current don to be public and still experience the issue? remoteCapabilityDONs comes from publicDONs so I think that's true.
I think you can fix this by using myDONs instead
| // filterLocalCapabilitiesFromRemote returns remoteDONs with every capability ID that is hosted by one | ||
| // of myCapabilityDONs removed from their capability configurations. The inputs are not mutated. | ||
| // This method still leaves room for the same capability to exist on different remote DONs. | ||
| func filterLocalCapabilitiesFromRemote(remoteDONs, myCapabilityDONs []registry.DON) []registry.DON { |
There was a problem hiding this comment.
It would be better to have this sort of policy logic in addRemoteCapabilities instead, that's where we make other policy decisions atm -- iterate over remoteDON.CapabilityConfigurations, check whether myDON has a matching capability, and refuse to add a remote cap if that's true
|
Ticket: https://smartcontract-it.atlassian.net/browse/PLEX-3442