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

fix(controller): node message should be updated when lock msg changed #13648

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

chengjoey
Copy link
Contributor

Fixes #13629

Motivation

When the sync lock is not released, the latest lock-msg is always used as the node message

@chengjoey
Copy link
Contributor Author

/hold
add test

@chengjoey
Copy link
Contributor Author

/hold cancel

@MasonM
Copy link
Contributor

MasonM commented Sep 25, 2024

@chengjoey FYI: I entered #13660 to fix the flaky tests. After that's merged, click the "Update branch" button at the bottom of the PR

@blkperl blkperl added area/controller Controller issues, panics area/mutex-semaphore labels Sep 30, 2024
@Joibel
Copy link
Member

Joibel commented Oct 1, 2024

/hold cancel

@chengjoey is this ready for review, I'm unsure of what you meant by this comment?

@chengjoey
Copy link
Contributor Author

/hold cancel

@chengjoey is this ready for review, I'm unsure of what you meant by this comment?

yeah, it is ready for review, since I didn't add the test at first, I used /hold cancel to get ready after adding the test

Copy link
Member

@Joibel Joibel left a comment

Choose a reason for hiding this comment

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

As a follow up to this it would be possible to list all of the failing locks rather than just the first, so if you feel like doing that it would be useful.

require.NoError(t, err)
woc := newWorkflowOperationCtx(wf, controller)
if !lockAcquired {
Copy link
Member

Choose a reason for hiding this comment

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

This feels wrong for a test.

Surely the outcome of TryAquire should always be the same for this test, and therefore we could assert that !lockAcquired? If lockAquired is true here we're not testing the new functionality.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done~, I modified the test case and handed over the modification of msg and status to operate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Templated mutex name not resolved
4 participants