- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1.9k
 
[CRE-941] Dynamic config updates in TriggerPublisher + ExecutableClient/Server #19702
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
Conversation
| 
           I see you updated files related to  
  | 
    
f35221b    to
    3f734c3      
    Compare
  
    6060e0c    to
    190a3de      
    Compare
  
    | 
               | 
          ||
| func (c *client) Start(ctx context.Context) error { | ||
| return c.StartOnce(c.Name(), func() error { | ||
| cfg := c.cfg.Load() | 
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 think this is non-recoverable.
if you pass a bad config, and call start, then call setConfig with a good config, and call start does it start?
i don't think it will. is there a test?
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.
all make a typed error for the caller to check if you want them to handle it ~
var ErrConfigNotSet = errors.New(...)
...
return fmt.Errorf("%w: empty remote capabilty", ErrConfigNotSet)
++ caller ++
err : = x.Start()
if errors.Is(ErrConfigNotSet) {
x.SetConfig
}
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.
Launcher will cache the shim only when Start() succeeded. Otherwise it will be re-created on each iteration with fresh config. It wasn't implemented consistently for all 4 cases but I now fixed it and added comments to point it out. Thanks!
| if errCfg := execCap.SetConfig(info, myDON.DON, defaultTargetRequestTimeout, nil); errCfg != nil { | ||
| return nil, fmt.Errorf("failed to set trigger config: %w", errCfg) | ||
| } | ||
| return execCap.(capabilityService), nil | 
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.
type check here? in prinicple can panic and kill the node
x, ok := exec.Cap.(capabilityService)
if !ok {
return nil, fmt.Errorf("failed to convert a into b...")
}
return x, nil
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.
Feels a bit excessive. Panic will be caught by unit tests, if the actual object is ever changed to not implement the interface any more.
190a3de    to
    43e8ccd      
    Compare
  
    | wg sync.WaitGroup | ||
| } | ||
| 
               | 
          ||
| type dynamicConfig struct { | 
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.
maybe some sort of "version" tag field could make it easier in debugging and logs, knowing which config are we currently dealing with application wide?
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.
We don't store any version onchain so it's not really possible to map it to anything sensible here.
Launcher calls SetConfig() on every iteration, even if values didn't change so an update timestamp also doesn't make too much sense...
| return errors.New("requestTimeout must be positive") | ||
| } | ||
| // Use a sensible default if maxParallelRequests is not set or is 0 | ||
| if maxParallelRequests <= 0 { | 
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.
Setting this will have no impact once the server is started, ie it is not dynamically settable. This is intentional?
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.
Thanks for pointing this out. Making it dynamic will be a PITA and it's also not very important... I added a warning log for now.
43e8ccd    to
    cb82ba6      
    Compare
  
    4b7a76f    to
    df4672f      
    Compare
  
    df4672f    to
    0ca8226      
    Compare
  
    
          
 | 
    




Follow up to #19404, which covers all remaining remote shims.
Move most config out of constructors and into setters.