Updating existing alias does not appear to work

[PodStuart]

I am using version 1.0.0-canary.4 and running tf-next alias set <my alias> <deployment id> --force to update an existing alias to point at a new deployment. However when I access my application the change is not being reflected. It feels like a cache somewhere has not been invalidated but I'm not entirely sure where.

[PodStuart]

I've tried a couple of things which have not worked.

1. Disabling browser caching.
2. Invalidating the Proxy-Config CloudFront distribution.

[ofhouse]

Thanks for reporting. Can confirm that the creation of invalidations is not working correctly in the latest canary release. Currently evaluating different solutions to this problem since we plan to move from SQS to Lambda Step functions to handle the invalidation queue. Since we have to handle multiple deployments, we now need a mechanism to deduplicate invalidations when they are enqueued.

An update to this is planned in one of the next releases.

[PodStuart]

Nice one. I'll keep an eye on this and I'm happy to be involved in testing when this is resolved.

I did figure out today that invalidating both of the CloudFront distributions was sufficient as a workaround. It was necessary to do both otherwise stale application versions were still being served.

[ruskeyz]

Is there a way to manually remove an alias?

tf-next deployment rm <deployment-id> --force doesn't work. Same issue, /* invalidation of both CF distributions does work as a workaround (UPD)

[ofhouse]

Is there a way to manually remove an alias?

Yes, currently not mentioned in the documentation, but this should work:

1. List all aliases associated with a deployment: tf-next alias ls <deployment-id>
2. Remove an alias: tf-next alias rm custom-alias.example.com

Note that deployment aliases (the subdomain created when running tf-next deploy cannot be deleted with tf-next alias rm. They can only be deleted when the deployment is removed.

[david-vargas-blumer]

this problem persists