This PR fixes #87 by waiting on both a result and terminal status before marking a goal as completed.
The behavior is a bit tricky to simulate from a testing perspective as it's a race so I didn't add any new tests, but I ensured it passes the current suite and works for my case in practice.
I did a few things here:
Limited status updates to the status channel to give one source of truth for goal statuses rather than allowing feedback and result messages to also inject their own state.
Wait on both a result object and a terminal status to mark an action as completed.
Set the status of a goal to pending when it goes out over the wire so it is immediately marked as active.
Let me know if there are any questions and hope this helps!
What type of change is this?
[x] Bug fix in a backwards-compatible manner.
[ ] New feature in a backwards-compatible manner.
[ ] Breaking change: bug fix or new feature that involve incompatible API changes.
[ ] Other (e.g. doc update, configuration, etc)
Checklist
[x] I added a line to the CHANGELOG.rst file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
[x] I ran all tests on my computer and it's all green (i.e. invoke test).
[x] I ran lint on my computer and there are no errors (i.e. invoke check).
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] I have added necessary documentation (if appropriate)
This PR fixes #87 by waiting on both a result and terminal status before marking a goal as completed.
The behavior is a bit tricky to simulate from a testing perspective as it's a race so I didn't add any new tests, but I ensured it passes the current suite and works for my case in practice.
I did a few things here:
Let me know if there are any questions and hope this helps!
What type of change is this?
Checklist
CHANGELOG.rstfile in theUnreleasedsection under the most fitting heading (e.g.Added,Changed,Removed).invoke test).invoke check).