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

Implement the functionality to just wait for the last event when dumping history events #470

Merged
merged 6 commits into from
Dec 22, 2017

Conversation

wxing1292
Copy link
Contributor

…vent of when dumping history events

@wxing1292 wxing1292 self-assigned this Dec 15, 2017
@wxing1292 wxing1292 requested a review from samarabbas December 15, 2017 03:45
@coveralls
Copy link

Coverage Status

Coverage increased (+0.09%) to 66.282% when pulling 71df3cb on waiting-until-end into d4204d7 on dedup.

20: optional string runId
30: optional shared.TaskList tasklist
40: optional bool isWorkflowRunning
// the event ID in the history event table which represent last batch of events
50: optional i64 (js.type = "Long") lastFirstEventId
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably a good time to rename this API.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

already done in #464


// It is possible that we still have the events in the table even though the mutable state is gone
// Get the nextEventID from visibility store if we still have it.
visibilityResp, err := wh.visibitiltyMgr.GetClosedWorkflowExecution(&persistence.GetClosedWorkflowExecutionRequest{
Copy link
Contributor

Choose a reason for hiding this comment

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

Cleanup the code path where we read/write NextEventID to closed workflow execution visibility store after completion. Do make sure it is not getting used anywhere else.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

searching using vs code
the call GetClosedWorkflowExecution only appears in:
VisibilityManager.go
cassandraVisibilityPersistence_test.go
cassandraVisibilityPersistence.go
visibilityInterfaces.go

so i think we are good

return nil, wh.error(err, scope)
}
// since getHistory func will not return empty history, so the below is safe
history.Events = history.Events[len(history.Events)-1 : len(history.Events)]
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you validate there is atleast one event returned by GetHistory?
Emit an error log incase no event is returned back.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -285,6 +285,7 @@ func (e *historyEngineImpl) StartWorkflowExecution(startRequest *h.StartWorkflow
if err1 != nil {
return nil, err1
}
msBuilder.executionInfo.LastFirstEventID = *startedEvent.EventId
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you use the generated Getter

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

history.Events = events
if !token.IsWorkflowRunning {
history.Events = []*gen.HistoryEvent{}
if isCloseEventOnly {
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably it makes sense to push the filter all the way down to history service.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

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 using the int64 max as expected next event ID

@@ -127,6 +127,7 @@ type (
ExecutionContext []byte
State int
CloseStatus int
LastFirstEventID int64
Copy link
Contributor

Choose a reason for hiding this comment

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

You need persistence changes to read/write this new field.

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

@wxing1292 wxing1292 force-pushed the waiting-until-end branch 2 times, most recently from ec6264b to b4b1fc0 Compare December 18, 2017 07:50
@cadence-workflow cadence-workflow deleted a comment from coveralls Dec 18, 2017
@cadence-workflow cadence-workflow deleted a comment from coveralls Dec 18, 2017
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 66.34% when pulling d80a4d0 on waiting-until-end into d16995c on dedup.

Copy link
Contributor

@samarabbas samarabbas left a comment

Choose a reason for hiding this comment

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

Looks good. One minor comment. You can check it in after fixing it.

@@ -360,6 +360,7 @@ type (
WorkflowTimeout int32
DecisionTimeoutValue int32
ExecutionContext []byte
LastFirstEventID int64
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we just define this as a constant? This will always have a fixed value.

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

@wxing1292 wxing1292 merged commit 6f5e990 into dedup Dec 22, 2017
@wxing1292 wxing1292 deleted the waiting-until-end branch December 22, 2017 19:29
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.02%) to 66.879% when pulling 55aa3ab on waiting-until-end into 94819c1 on dedup.

@wxing1292 wxing1292 restored the waiting-until-end branch January 3, 2018 02:15
@wxing1292 wxing1292 deleted the waiting-until-end branch January 3, 2018 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants