Expand Azure register warning context

[jwhitlock]

Add workerPoolId, providerId, and workerId to registration-error-warning context, logged from the Azure provider's register() function in worker-manager.

Add workerState to the warning context when the state is not REQUESTED, to help diagnose registration with an unexpected state.

Github Bug/Issue: #4999 (helps diagnose, doesn't yet fix)

[djmitche]

Changes look good to me otherwise, but I don't know if you still want my review :)

[jwhitlock]

I added a yarn generate commit, needed because I changed the spec for registrationErrorWarning.

The remaining failure of service-secrets is a intermittent network error when installing the yarn packages. This step passed on the last round, so I think this can be ignored.

[petemoore]

Looks great, thanks John!

[jwhitlock]

Every time I think about merging this, I look at the repeated code and think there must be a way to get those variables automatically into the logging context.

I'm still holding off until 1) I can research that, or 2) we cut a new TC version

[djmitche]

Inside this method (so, inside the scope wehre workerPool, this, and worker are defined), you could define a closure to do this:

   let logRegError = (err, message) => {
      this.monitor.log.registrationErrorWarning({
        message, err,
        workerPoolId: workerPool.workerPoolId,
        providerId: this.providerId,
        workerId: worker.workerId,
      });

Another option is to make a child logger that contains some of those values, but then you're passing a reference to that logger everywhere.

TBH I wouldn't worry about the verbosity here.

[jwhitlock]

option 3 - Add a comment and Dustin will prototype the solution 😁

Thanks! I'm going to try the closure, see what it looks like.

[jwhitlock]

I ran out of time to make this look nice. Maybe when someone re-writes the Azure provisioner they can fix this...