"watch" doesn't appear to paginate stack events

[dannosaur]

Something I've noticed recently that's been bugging me. When watching a stack, either through watch-stack or another method that ends up doing a "watch", the more the stack gets updated (and therefore the more events it has), the longer it takes iidy to update to reflect the stack's current status.

For instance, I have a few stacks that are regularly updated by a CI. Each update causes 10's of events to be registered. Effectively these stacks have thousands, if not tens of thousands of events. What I think is happening is that iidy is downloading all the events from CFN in chronological order, from the earliest to the latest. The API (thus proven by the aws CLI tool) certainly supports ordering in descending chronological order, and limiting the number of events returned. For instance, aws cloudformation describe-stack-events --stack-name <my-stack-name> --max-items 100 returns in just a few seconds.

Thus when making changes to these regularly-updated stacks with iidy, the stack completes the update long before iidy reflects the same result. In some cases, another stack update might have been queued by the CI and has started before iidy's even registered that its own update has completed, therefore iidy incorrectly registers the stack update as "failed" because the status is "UPDATE_IN_PROGRESS".

Is it possible to change the way iidy pulls stack events so that it's a lot quicker? Getting the events in descending chronological order and limiting the number of events returned to something reasonable would probably resolve this issue.

[tavisrudd]

Yeah, it looks like we're missing the --events flag present on describe-stack. I'll look into adding that this week. I'll fix it on watch-stack first then investigate update-stack etc.

[tavisrudd]

This turned out to be a little bit more complicated than expected so I'm going to cut another release in a bit with it. The js sdk doesn't expose a MaxItems argument for the events. Rather it paginates if the first page hits > 1MB of event data.