Skip to content
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.

Remove deprecated events #826

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

ckiosidis
Copy link
Contributor

Hey, I just made a Pull Request!

Description

Motivation and Context

Have you tested this? If so, how?

Checklist for PR author(s)

  • Changes are covered by unit test
  • All tests pass
  • Code coverage check passes
  • Error handling is tested
  • Errors are handled at the appropriate layer
  • Errors that cannot be handled where they occur are propagated
  • (optional) Changes are covered by system test
  • Relevant documentation updated
  • This PR has NO breaking change to public API
  • This PR has breaking change to public API and it is documented

Checklist for PR reviewer(s)

  • This PR has been incorporated in release note for the coming version
  • Risky changes introduced by this PR have been all considered

@ckiosidis ckiosidis changed the title Remove depricated events Remove deprecated events Apr 22, 2020
return state(RUNNING);
case PREPARE:
return state(RUNNING, data().builder()
.tries(data().tries() + 1)
Copy link
Contributor

Choose a reason for hiding this comment

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

@honnix do you know why we allow this transition from PREPARE directly to RUNNING? Is it in case we lose the events in between?

fyi, we added this change to keep track of the number of tries here because we found that this would be a path in the state machine that doesn't increment tries at any other transition. Not sure it's the right thing to do though.

Copy link
Member

Choose a reason for hiding this comment

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

I don't know what the reason was. Missing tries increase on that transition branch was introduced by #33.

I doubt bypassing submitting and submitted states would actually work when executing a workflow instance because that would mean missing many things. During replay, this tries is not important I think.

My suggestion is we can remove support of this transition.

Copy link
Member

Choose a reason for hiding this comment

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

BTW there are a few things in this file marked as backward compatibility, e.g. https://github.com/spotify/styx/pull/826/files#diff-05de7b680cea03b57e3a1df7bbbc1258R179 . I think we can also kill those.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, thanks for the input. I think we'll do that as part of a following PR just to keep this PR limited in scope.

@codecov
Copy link

codecov bot commented Apr 24, 2020

Codecov Report

Merging #826 into master will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #826      +/-   ##
============================================
+ Coverage     91.62%   91.75%   +0.12%     
+ Complexity     1924     1921       -3     
============================================
  Files           177      177              
  Lines          7550     7510      -40     
  Branches        459      456       -3     
============================================
- Hits           6918     6891      -27     
+ Misses          521      510      -11     
+ Partials        111      109       -2     

@@ -53,7 +53,7 @@
import org.mockito.MockitoAnnotations;

@RunWith(JUnitParamsRunner.class)
public class TimeoutHandlerTest {
public class TimeoutHandlerTest {
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be unintended change.

@@ -310,243 +296,234 @@ public void testRetryDelayFromQueued() {
}

@Test
public void testRetryFromRunError() {
public void testRetryAfterFromRunError() {
Copy link
Member

Choose a reason for hiding this comment

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

I think this test case meant to test a state after dequeue happens after retryAfter.

assertThat(transitioner.get(WORKFLOW_INSTANCE).data().consecutiveFailures(), equalTo(1));
}

@Test
public void testManyRetriesFromRunError() {
public void testManyRetriesAfterFromRunError() {
Copy link
Member

Choose a reason for hiding this comment

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

I think this test case meant to test a state after dequeue happens after retryAfter.

assertThat(transitioner.get(WORKFLOW_INSTANCE).data().consecutiveFailures(), equalTo(0));
}

@Test
public void testRetryFromTerm() {
public void testRetryAfterFromTerminated() {
Copy link
Member

Choose a reason for hiding this comment

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

I think this test case meant to test a state after dequeue happens after retryAfter.

assertThat(transitioner.get(WORKFLOW_INSTANCE).data().consecutiveFailures(), equalTo(1));
}

@Test
public void testManyRetriesFromTerm() {
public void testManyRetriesAfterFromTerminated() {
Copy link
Member

Choose a reason for hiding this comment

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

I think this test case meant to test a state after dequeue happens after retryAfter.

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.

5 participants