[v13] integrations/operator: re-use the teleport client instead of creating a new one#34431
Conversation
… a new one (#34050) * integrations/operator: re-use the teleport client instead of creating a new one * fix race condition * address feedback + add godocs
| teleportClient, release, err := r.TeleportClientAccessor(ctx) | ||
| if err == nil { | ||
| defer release() | ||
| } |
There was a problem hiding this comment.
Why are we not returning an error when err != nil ?
There was a problem hiding this comment.
Because we are processing the error and reporting it in the status, so we don't want to exit yet. A few lines below the error is aggregated with the status update error. err handling continues below.
We have 4 cases:
- err != nil, updaterErr != nil
- err != nil, updaterErr == nil
- err == nil, updateErr != nil
- err == nil, updaterErr != nil
We must release the teleportClient only on the last two cases, we can do two release invocation (one in the if err != nil || updateErr != nil { block, and one after) or do a single one before, then continue to process errors.
There was a problem hiding this comment.
I was scrolling and the pattern was different for the Role
But it seems it was already the case anyway
👍
| teleportClient, release, err := r.TeleportClientAccessor(ctx) | ||
| if err == nil { | ||
| defer release() | ||
| } |
There was a problem hiding this comment.
I was scrolling and the pattern was different for the Role
But it seems it was already the case anyway
👍
…reating a new one (#34050)
Manual backport of #34050 to branch/v13