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

statemgr: add a NewUnlockErrorFull state manager for tests #25823

Merged
merged 2 commits into from
Aug 14, 2020

Conversation

mildwonkey
Copy link
Contributor

I've frequently needed to coerce Unlock() errors for tests and it's been
awkward and fraught every time, so I decided to add a full state manger
that returns mostly errors. I intend to use this in conjunction with
the clistate.Locker interface, which first calls statemgr.Lock() (to block if the
mutex is in use) at the start of clistate.Unlock(), so statemgr.Lock() rather awkwardly needed to succeed.

I've frequently needed to coerce Unlock() errors for tests and it's been
awkward and fraught every time, so I decided to add a full state manger
that returns *mostly* errors. I intend to use this in conjunction with
the clistate.Locker interface, which first calls Lock() (to block if the
mutex is in use) at the start of Unlock(), so Lock() rather awkwardly needed to succeed.
@mildwonkey mildwonkey requested a review from a team August 12, 2020 15:10
@codecov
Copy link

codecov bot commented Aug 12, 2020

Codecov Report

Merging #25823 into master will decrease coverage by 0.01%.
The diff coverage is 0.00%.

Impacted Files Coverage Δ
states/statemgr/statemgr_fake.go 44.68% <0.00%> (-18.96%) ⬇️
dag/marshal.go 53.33% <0.00%> (-1.12%) ⬇️

Copy link
Contributor

@alisdair alisdair left a comment

Choose a reason for hiding this comment

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

This looks good to me in isolation! 👍 I'm not familiar with tests that would use this, so I can't quite picture how it'd be used. If you have one to hand, could you point at a test where you'd use it?

fakeP Transient

lockLock sync.Mutex
locked bool
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see any of the struct members other than t being used in the methods below. Would it make sense to remove them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honestly I don't think we need any of the struct members, since all the state functions return errors. I'll remove them all!

@mildwonkey
Copy link
Contributor Author

mildwonkey commented Aug 14, 2020

Absolutely @alisdair , I should have included this from the start. The community PR that pushed me over the edge is this one: #25729

The Unlock function first locks the state, which is why I needed a statemgr that would return success (and a non-empty lockId) for lock and an error for unlock:

func (l *locker) Unlock(parentErr error) error {
l.mu.Lock()
defer l.mu.Unlock()
if l.lockID == "" {
return parentErr
}

And here's the very simple test I have ready to add to that PR:

func TestUnlock(t *testing.T) {
	ui := new(cli.MockUi)

	l := NewLocker(context.Background(), 0, ui, &colorstring.Colorize{Disable: true})
	l.Lock(statemgr.NewUnlockErrorFull(nil, nil), "test-lock")

	err := l.Unlock(nil)
	if err == nil {
		t.Error("expected unlock error")
	}
}

@mildwonkey mildwonkey merged commit 95eca06 into master Aug 14, 2020
@mildwonkey mildwonkey deleted the mildwonkey/statemgr-error-full branch August 14, 2020 18:14
genx7up pushed a commit to aweps/terraform that referenced this pull request Aug 14, 2020
…#25823)

* statemgr: add a NewUnlockErrorFull state manager for tests

I've frequently needed to coerce Unlock() errors for tests and it's been
awkward and fraught every time, so I decided to add a full state manger
that returns *mostly* errors. I intend to use this in conjunction with
the clistate.Locker interface, which first calls Lock() (to block if the
mutex is in use) at the start of Unlock(), so Lock() rather awkwardly needed to succeed.
@ghost
Copy link

ghost commented Sep 14, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Sep 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants