Skip to content

Report errors from unstable jobs#333

Merged
albertvaka merged 4 commits into
masterfrom
albertvaka/send-unstable-message-as-error
Feb 27, 2023
Merged

Report errors from unstable jobs#333
albertvaka merged 4 commits into
masterfrom
albertvaka/send-unstable-message-as-error

Conversation

@albertvaka

Copy link
Copy Markdown
Collaborator

What does this PR do?

If a job is unstable there might be a "warning" message associated. Read it and report it in the error field.

Review checklist (to be filled by reviewers)

  • Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
  • PR title must be written as a CHANGELOG entry (see why)
  • Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
  • PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
  • PR should not have do-not-merge/ label attached.
  • If Applicable, issue must have kind/ and severity/ labels attached at least.

If a job is unstable there might be a "warning" message associated.
Read it and report it in the error field.
@albertvaka albertvaka added the changelog/Added Added features results into a minor version bump label Feb 17, 2023
andrea-mosk
andrea-mosk previously approved these changes Feb 20, 2023

@andrea-mosk andrea-mosk left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Looks good to me. Could we add a test for this?

}

public boolean isUnstable() {
return "unstable".equalsIgnoreCase(this.result);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

could we have this precalculated? string equals has more overhead than having a boolean field

@albertvaka albertvaka Feb 22, 2023

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

If we precalculate it there's more room for error (eg: we have to remember to update isError and isUnstable in setResult) and taking into account it's only called 2 times per span, I don't think it's worth the optimization.

I know performance overhead has been sometimes an issue for some customers, but I don't think the impact of this is noticeable (compared to, for example, the call to hostname we make once for every span).

if(node.isError() && !parent.isError()) {
propagateResultToAllParents(node, "error");
} else if(node.isUnstable() && !parent.isUnstable()) {
propagateResultToAllParents(node, "unstable");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Should we make this a constant, perhaps? There're 12 places where this literal is used

@albertvaka
albertvaka merged commit 3956ae1 into master Feb 27, 2023
@albertvaka
albertvaka deleted the albertvaka/send-unstable-message-as-error branch February 27, 2023 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/Added Added features results into a minor version bump

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants