Error handling for non existent drill downs

[timbrigham]

I've noticed that if I use Get-LrAieDrilldown in a smart response it's quite possible to have it execute prior to the logs being added to the alarm, resulting in something like the following for several seconds after the call.

Get-LrAieDrilldown -AlarmId 108939

AlarmID           :
AlarmGuid         :
Priority          :
AIERuleName       :
Status            :
Logs              : {}
SummaryFields     : {}
NotificationSent  :
EventID           :
NormalMessageDate :
AIEMsgXml         :

I can work around this by checking for values / sizes of the data returned and retrying the API call, but it seemed odd enough to mention here.

[GeneCupstid]

Thanks @timbrigham - I have a fix for this. I will be uploading within the next day or so.

(from new comment-based help)

        To mitigate this, Get-LrAieDrilldown will reattempt the request 
        (18) times, waiting (10 seconds) between each attempt. These
        values can be modified by specifying the RetryAttempts and
        RetryWaitSeconds parameters. This should be sufficient for the
        majority of alarms unless the platform is under heavy load.

[GeneCupstid]

Also, the longest time I've encountered so far is just over 2 minutes, which was a peak event time during the day - though I'm not sure what others are used to seeing. :)

Since implementing this version, my SRPs have had no issues with getting drilldowns. That's been running for about a week.

[timbrigham]

Thanks @GeneCupstid. So far my response times tend to be around 30 seconds or less. I'll pull down the new version shortly. :)

[Jt3kt]

Just checking in here, how're we looking on the builtin handler for this?

[timbrigham]

Apologies, I've been working on other projects. I'll pull the latest version and get back to you.

[GeneCupstid]

This is implemented. Going forward we will track the PRs more appropriately so these can be properly linked.