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

[ResponseOps][TaskManager] TaskTypeDictionary::get() no longer throws #189591

Merged
merged 2 commits into from
Aug 2, 2024

Conversation

pmuellr
Copy link
Member

@pmuellr pmuellr commented Jul 31, 2024

resolves #189560

Summary

Removes the throw from TaskTypeDictionary::get() and have it return TaskDefinition | undefined instead.

Then fix all the places that breaks. This could probably never happen when a task is running - the definition would be needed for a bunch of things prior to this (like polling for the task). However, it has occurred during metric generation, and likely more code in the future will use this, so the new API has less of a "suprise! Error!" aspect to it, for such an innocent looking method name.

Several places in the existing code did not have to be changed as they already guards for checking null-ish returns from the method :-)

…ow`s

resolves elastic#189560

Removes the `throw` from `TaskTypeDictionary::get()` and have it
return `TaskDefinition | undefined` instead.

Then fix all the places that breaks.  This could probably never happen
when a task is running - the definition would be needed for a bunch
of things prior to this (like polling for the task).  However, it has
occurred during metric generation, and likely more code in the future
will use this, so the new API has less of a "suprise! Error!" aspect
to it, for such an innocent looking method name.

Several places in the existing code did not have to be changed as they
already guards for checking null-ish returns from the method :-)
@pmuellr pmuellr added release_note:skip Skip the PR/issue when compiling release notes Feature:Task Manager Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Jul 31, 2024
@pmuellr pmuellr requested a review from a team as a code owner July 31, 2024 02:20
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

Copy link
Contributor

@adcoelho adcoelho left a comment

Choose a reason for hiding this comment

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

Looks straightforward 😅

// In the scenario the task is unused / deprecated and Kibana needs to manipulate the task,
// we'll do a pass-through for those
if (!this.definitions.has(task.taskType)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

surprised there's no unit test for validating an unknown task type to update. Maybe we should add one?

Copy link
Member Author

Choose a reason for hiding this comment

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

Do these not cover that?

describe('getValidatedTaskInstanceFromReading()', () => {
it(`should return the task as-is whenever the task definition isn't defined`, () => {
const definitions = new TaskTypeDictionary(mockLogger());
const taskValidator = new TaskValidator({
logger: mockLogger(),
definitions,
allowReadingInvalidState: false,
});
const task = taskManagerMock.createTask();
const result = taskValidator.getValidatedTaskInstanceFromReading(task);
expect(result).toEqual(task);
});

describe('getValidatedTaskInstanceForUpdating()', () => {
it(`should return the task as-is whenever the task definition isn't defined`, () => {
const definitions = new TaskTypeDictionary(mockLogger());
const taskValidator = new TaskValidator({
logger: mockLogger(),
definitions,
allowReadingInvalidState: false,
});
const task = taskManagerMock.createTask();
const result = taskValidator.getValidatedTaskInstanceForUpdating(task);
expect(result).toEqual(task);
});

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see. I didn't realize it was using definitions.has which doesn't throw anyway not definitions.get.

@pmuellr
Copy link
Member Author

pmuellr commented Jul 31, 2024

/ci

Copy link
Member

@umbopepato umbopepato left a comment

Choose a reason for hiding this comment

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

LGTM!

@pmuellr
Copy link
Member Author

pmuellr commented Aug 2, 2024

Can't tell what's going on with the build errors - looks systematic, maybe ES didn't come up correctly? Going to start merge main to run again, and poke around those tests a bit ...

@pmuellr
Copy link
Member Author

pmuellr commented Aug 2, 2024

@elasticmachine merge upstream

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@pmuellr pmuellr merged commit d0c644d into elastic:main Aug 2, 2024
38 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Task Manager release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[ResponseOps][TaskManager] remove the throw from TaskTypeDictionary::get()
7 participants