[ECS] [request]: Match the status retrieved from the task metadata endpoint with the actual task status

[masakihr]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request Plese match the value of KnownStatus retrieved from the task metadata endpoint with the value of lastStatus from the response of DescribeTasks API.

Which service(s) is this request for? ECS Agent

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Currently, there is the below difference between the KnownStatus retrieved from the task metadata endpoint and the lastStatus from the DescribeTasks API response.

• lastStatus: RUNNING -> DEACTIVATING-> STOPPED
• KnownStatus: RUNNING -> STOPPED

Therefore, it is currently not possible to perform a graceful shutdown after detecting the DEACTIVATING status within the task.

Are you currently working around this issue? Handling Task state change events is a workaround.

Additional context ECS Agent 1.70.2

[pattersam]

In my case, I also experience this with the DesiredStatus field in the v4 ECS Fargate metadata endpoint JSON.

It remains as RUNNING even though the AWS ECS Console UI says that the desired status is STOPPED (caused by a scale-in event).

In my case, I would like to use the metadata endpoint to know when the task is in the 'deregistration delay' period of a ALB target group (where it is marked as stopped but not yet killed for a configurable amount of time, typically 5 minutes).

I would consider this a bug, because I would expect that the data received from the metadata endpoint would reflect reality (especially a status field), at least after some short period to allow it to be syncronised.

[mgoodings]

Why has this not been fixed? The endpoint is not functioning correctly. We just built a feature around the AWS docs specification for this endpoint and it just flat out doesn't work as documented.

We need a way to know when the container is in a DEACTIVATING status so we can spin down background workers during a deployment.