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

IWF-186: Upgrade Temporal SDK #442

Merged
merged 17 commits into from
Oct 11, 2024
Merged

IWF-186: Upgrade Temporal SDK #442

merged 17 commits into from
Oct 11, 2024

Conversation

lwolczynski
Copy link
Contributor

@lwolczynski lwolczynski commented Oct 8, 2024

Description

Checklist

  • Code compiles correctly
  • Tests for the changes have been added
  • All tests passing
  • This PR change is backwards-compatible
  • This PR CONTAINS a (planned) breaking change (it is not backwards compatible)

Related Issue

Closes #434

@lwolczynski lwolczynski marked this pull request as ready for review October 9, 2024 14:34
@lwolczynski
Copy link
Contributor Author

To review: TestAnyCommandCombinationWorkflowTemporal test passes locally, fails in Gitlab CI

@lwolczynski lwolczynski force-pushed the jira/lwolczynski/IWF-186 branch 2 times, most recently from 739ee79 to 456682c Compare October 9, 2024 15:50
@@ -116,7 +116,7 @@ func doTestLockingWorkflow(t *testing.T, backendType service.BackendType, config
ValueType: iwfidl.INT.Ptr(),
},
}
time.Sleep(time.Second * 1)
time.Sleep(time.Second * 2)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Test passes locally with no change. I had to bump it to make the test pass in Github CI

Copy link
Contributor

Choose a reason for hiding this comment

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

I am still not sure why we need more sleep. I remember there is a new behavior in temporal cloud that they now enforce a backoff of 1s for each continueAsNew to prevent having too fast continueAsNew which cause hot partition in server. Maybe that's the cause. we can dig into the release logs to confirm, or maybe ask them

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm looking into this, but it's not easy to troubleshoot since it passes locally

Copy link
Contributor

Choose a reason for hiding this comment

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

I just looked into that, looks like there is a test panic at timeout for the cadence cases

@@ -108,7 +108,7 @@ func doTestAnyCommandCombinationWorkflow(t *testing.T, backendType service.Backe
panicAtHttpError(err, httpResp)

// skip the timer for S1
time.Sleep(time.Second * 2) // wait for a second so that timer is ready to be skipped
time.Sleep(time.Second * 5) // wait for a few seconds so that timer is ready to be skipped
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same here

integ/do_nothing_test.go Outdated Show resolved Hide resolved
service/api/temporal/reset.go Outdated Show resolved Hide resolved
service/api/temporal/client.go Outdated Show resolved Hide resolved
Comment on lines +186 to +188
# Fails CI when used with -coverprofile flag due to tests that panic; see https://go.dev/doc/build-cover#panicprof
# $Q go test -v ./... -timeout 15m -cover -coverprofile coverage.out -coverpkg ./service/...
$Q go test -v ./... -timeout 15m
Copy link
Contributor Author

@lwolczynski lwolczynski Oct 11, 2024

Choose a reason for hiding this comment

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

@longquanzheng CI issue is caused by Go upgrade from 1.19 to 1.22

Beginning in Go 1.20, Go supports collection of coverage profiles from applications and from integration tests, larger and more complex tests for Go programs.

If my program panics, will coverage data be written?
Programs built with go build -cover will only write out complete profile data at the end of execution if the program invokes os.Exit() or returns normally from main.main. If a program terminates in an unrecovered panic, or if the program hits a fatal exception (such as a segmentation violation, divide by zero, etc), profile data from statements executed during the run will be lost.

When tests panic, the task returns "Error 1" which fails the Github Action. We should fix it by refactoring tests, but I removed the coverage options to unblock for now

https://go.dev/doc/build-cover#panicprof

Copy link
Contributor

Choose a reason for hiding this comment

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

Good finding! Thanks!!!

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Upgrade temporal sdk to latest and golang version to 1.21.x
2 participants