[PowerShell][Request] Allow for retry on certain failures about autorest.powershell HOT 6 CLOSED

@deathly809

Is this something you'd like to implement once across all cmdlets, or are you thinking it would only apply to specific cmdlets?

If it's once for everything, then I can add an extensibility point in the Module class where you could create a 'Module.cs' file in the custom folder:

namespace Sample.API.Whatever { 
public partial class Module {

void AfterCreatePipeline(System.Management.Automation.InvocationInfo invocationInfo, ref Microsoft.Azure.PowerShell.Cmdlets.BridgeAdmin.Runtime.HttpPipeline pipeline) 
{
  // append this step to the 
  pipeline.Append(retryOn427);
}

public async System.Threading.Tasks.Task<System.Net.Http.HttpResponseMessage> retryOn427( System.Net.Http.HttpRequestMessage requestMessage, Runtime.IEventListener listener, Runtime.ISendAsync next ) 
{
  var count = 3;
  System.Net.Http.HttpResponseMessage result = null;
            
  while( true ) 
  {
    // make the call 
    result = await next.SendAsync(requestMessage,listener);

    // check to see if we want to retry
    if( 427 == (int)result.StatusCode && count-- >= 0  ) {
      // wait before retrying
      await System.Threading.Tasks.Task.Delay(10000);
      continue;
    } 

    // apparently not retrying, let's get out.
    break;
  };

  // return whatever we have.
  return result;
}

}
}

from autorest.powershell.

@fearthecowboy This is for specific cmdlets I believe. Usually related cmdlets which might cause a service to migrate to another node which would cause a blip and the cmdlet to fail. I don't think it would hurt to add it for an entire module though. I will need to reach out to the team that asked for this, we had a re-org and I need to find out who owns this now.

from autorest.powershell.

Hopefully it's ok for all, if its not, I'm pretty sure I can give you another alternative that tweaks the pipeline on a per-cmdlet basis; the only downside is that you'd have to implement tiny partial class for each one.

It's also possible I could craft a directive you could use.

G

from autorest.powershell.

@fearthecowboy I can't imagine anything bad can happen. But, that is how bugs happen I guess lol.

Too bad we can provide a class that allows us to Inherit from your class where we can define a method that you call after you add all the default handlers i.e

public async System.Threading.Tasks.Task<System.Net.Http.HttpResponseMessage> FinalHandler( System.Net.Http.HttpRequestMessage requestMessage, Runtime.IEventListener listener, Runtime.ISendAsync next );

from autorest.powershell.

That's actually not too hard to implement -- generated cmdlets only inherit from PSCmdlet -- we don't force a weird base class.

Would be a small directive to alter the inheritance on a subset of cmdlets so you could make a class inherit from PSCmdlet and the generated cmdlets could inherit from that.

I was thinking of that ; just want to see if a partial method in a child class can be fulfilled by a base class.

from autorest.powershell.

@fearthecowboy What would the tag thing entail? Could we provide something in the spec itself? Something like x-ms-failover-aware?

from autorest.powershell.