Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

acs: add an empty task in TaskStateChange for unrecognized tasks #1467

Merged
merged 1 commit into from
Aug 14, 2018

Conversation

haikuoliu
Copy link
Contributor

@haikuoliu haikuoliu commented Jul 25, 2018

Summary

Add an empty task in TaskStateChange for unrecognized tasks

This fixes a bug where unrecognized task cannot be stopped

Implementation details

Currently when Agent receives a task from ACS, if it's malformed and Agent cannot recognize it, it will be handled by handleUnrecognizedTask function. The handleUnrecognizedTask intends to send a task change event to stop the task, but it fails to do so, because it returns a TaskStateChange without a Task in it, and this will be discarded by taskHandler, as it should not be sent according to taskShouldBeSent

So this fix is to add an empty task in the result of handleUnrecognizedTask so that the task change will not be discarded.

Testing

  • Builds on Linux (make release)
  • Builds on Windows (go build -out amazon-ecs-agent.exe ./agent)
  • Unit tests on Linux (make test) pass
  • Unit tests on Windows (go test -timeout=25s ./agent/...) pass
  • Integration tests on Linux (make run-integ-tests) pass
  • Integration tests on Windows (.\scripts\run-integ-tests.ps1) pass
  • Functional tests on Linux (make run-functional-tests) pass
  • Functional tests on Windows (.\scripts\run-functional-tests.ps1) pass

Description for the changelog

Bug - Fixed a bug where unrecognized task cannot be stopped

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@haikuoliu haikuoliu added this to the 1.20.0 milestone Jul 25, 2018
@haikuoliu haikuoliu requested a review from a team July 25, 2018 00:00
@adnxn
Copy link
Contributor

adnxn commented Jul 25, 2018

@haikuoliu: was there a bug report for this? or how did we discover this gap? mostly just curious.

@adnxn
Copy link
Contributor

adnxn commented Jul 25, 2018

@haikuoliu: please add a unit test to cover this case

@haikuoliu
Copy link
Contributor Author

@adnxn I have added unit test for this.

@adnxn adnxn modified the milestones: 1.20.0, 1.20.1, 1.21.0 Aug 7, 2018
wait := &sync.WaitGroup{}
wait.Add(1)

mockECSACSClient.EXPECT().SubmitTaskStateChange(gomock.Any()).Do(func(x interface{}) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please check the Task field is not nil inside the mock call, probably something like this.

// The real task cannot be extracted from payload message, so we send an empty task.
// This is necessary because the task handler will not send an event whose
// Task is nil.
Task: &apitask.Task{},

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you do a nil check here, as the task isn't always nil here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarified offline.

Copy link
Contributor

@tehshwann tehshwann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of questions to clarify my understanding of this code.

mockECSACSClient.EXPECT().SubmitTaskStateChange(gomock.Any()).Do(func(change api.TaskStateChange) {
assert.NotNil(t, change.Task)
wait.Done()
// Don't return, verify timeout happens.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand this correctly, this test ensures that the handler deals with the empty task correctly. Are there other test cases we should be hitting? For example, does this handler code path get touched if the task is recognized but nill?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is to ensure that the SubmitTaskStateChange will be hit when there are unrecognized tasks. I added a not nil check here is because we manually create a non-nil task and pass it along the code path.

The unrecognized task means that the task cannot be converted to apitask.Task or some of the fields are not in correct format, so if it's a nil task then it should be a unrecognized task.

wait.Add(1)

mockECSACSClient.EXPECT().SubmitTaskStateChange(gomock.Any()).Do(func(change api.TaskStateChange) {
assert.NotNil(t, change.Task)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we allow unrecognized tasks to run and complete? If so, how do we know that the task state changes after this are handled ok?

i.e. Is the empty task passed on to another component? And if so, we we creating a new untested code path by creating the empty task?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't allow unrecognized tasks to run or complete. If it's unrecognized, we simply drop it and tell backend that this task is stopped because it's unrecognized.

To stop a task, we don't even need to specify a task struct when calling SubmitTaskStateChange API, The only purpose I added an empty task here is to make this task change not dropped by Agent, so that it will be sent to backend via SubmitTaskStateChange API.

haikuoliu added a commit to haikuoliu/amazon-ecs-agent that referenced this pull request Aug 10, 2018
@haikuoliu haikuoliu merged commit f0284ba into aws:dev Aug 14, 2018
@haikuoliu haikuoliu modified the milestones: 1.21.0, 1.20.2 Aug 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants