Hi all! I am struggling with the triggers on aws.apigateway.Deployment. I would like to create/replace the Deployment, so it would take any changes in my api gateway, so the Deployment would be the latest version. I managed to triggger it, if there are changes (creation or updates) in my resource path, or methods. But if methods are deleted, it would not trigger a new Deployment, so the old methods would stay. Am I doing something wrong, or is this the expected behaviour? How I create my Deployment:

private createApiGatewayDeployment(name: string, integrations: aws.apigateway.Integration[], resources: aws.apigateway.Resource[]): aws.apigateway.Deployment {
   const triggersHash = pulumi.all([
      integrations.map(m => m.id).sort(),
      resources.map(r => r.id).sort()
      ])
      .apply(([iIds, rIds]) => {
         return crypto.createHash('sha256')
            .update(JSON.stringify([iIds, rIds]))
            .digest('hex');
      })

   return new aws.apigateway.Deployment(`${name}-deployment`, {
      restApi: this.api.id,
      triggers: {
         redeploy: triggersHash
      }
   , {parent: this});
}

The Pulumi output:

...

  @ updating....
  
   +  aws:apigateway:Method xxx-PATCH-method creating (0s) 
  
      ...
      ...
      ...
  
  @ updating....
  .
  
   +  aws:apigateway:Method xxx-PATCH-method created (2s) 
  
  @ updating....
  
   +  aws:apigateway:Integration xxx-PATCH-integration creating (0s) 
  
  @ updating....
  .
  
   +  aws:apigateway:Integration xxx-PATCH-integration created (1s) 
  
  @ updating....
  
   ++ aws:apigateway:Deployment xxx-deployment creating replacement (0s) [diff: ~triggers]
  
  @ updating....
  .
  
   ++ aws:apigateway:Deployment xxx-deployment created replacement (1s) [diff: ~triggers]
  
  @ updating....
  
   +- aws:apigateway:Deployment xxx-deployment replacing (0s) [diff: ~triggers]
   +- aws:apigateway:Deployment xxx-deployment replaced (0.00s) [diff: ~triggers]
  
   ~  aws:apigateway:Stage xxx-stage updating (0s) [diff: ~deployment]
  
  @ updating....
  
   ~  aws:apigateway:Stage xxx-stage updated (1s) [diff: ~deployment]
  
  @ updating....
  .
  
   -- aws:apigateway:Deployment xxx-deployment deleting original (0s) [diff: ~triggers]
  
  @ updating....
  
   -- aws:apigateway:Deployment xxx-deployment deleted original (1s) [diff: ~triggers]
  
  @ updating....
  
   -  aws:apigateway:Integration xxx-ANY-integration deleting (0s) 
  
  @ updating....
  
   -  aws:apigateway:Integration xxx-ANY-integration deleted (1s) 
  
  @ updating....
  
   -  aws:apigateway:Method xxx-ANY-method deleting (0s) 
  
  @ updating....
  .
  
   -  aws:apigateway:Method xxx-ANY-method deleted (1s) 
  
  @ updating....

...

You can see that the Deployment is changed before the deletes are executed

It looks like you'll need to decouple the resource IDs from the resources, so that you're not removing a deleted resource from the Deployment before you update the Deployment. You could do this by storing the collection of IDs you've ever known about and creating the Deployment from that, instead of creating the Deployment from the collection of IDs you currently know about.

By storing the collection of IDs you mean to store it temporarily in S3 or DynamoDB or ...? Would that help, if some resources needs to be deleted, it will first delete the resources and then update the Deployment?

No, I meant keeping the IDs of managed resources in some other property, probably in a ComponentResource so the Pulumi persists it to state. Essentially you'll need to re-implement the deletion functionality because the built-in functionality requires a two-step deletion that your current logic is making happen in one step. Alternatively you could change the implementation to be two-step, but that's probably less desirable. Forcing someone to run

pulumi up

twice to delete a resource isn't a good solution. Someone will forget, and resources will end up not being deleted.

Okay I inderstand now, thanks for you answers Paul!