-
Notifications
You must be signed in to change notification settings - Fork 800
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
UNVERIFIED: fix nil panic due to nil msBuilder #6184
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
... and 12 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand. Was there a specific workflow that caused this, or was it a general panic somewhere?
After this fix, could you verify if the problem has been resolved?
The interconnection between hBuilder and mutable state looks like a weird architecture, and maybe requires a rework, but the change is fine as a temporary solution.
I don't have enough context to know the right place either, but if it builds and runs, probably ok then |
There's some kind of workflow that causes a consistent panic here, I've seen it a couple times with different workflows (I even have an older task from several months ago to look into it, and it just happened again). I suspect it has to do with it ending on a terminated event, but that's all I've got at the moment - a nil panic here, on a thing that seems like it should probably never be nil (but clearly is sometimes).
I haven't been able to reproduce it, so unfortunately no. But the code paths involved in setting (or not setting) this field are really only 2, so I'm pretty confident it fixes this panic. |
admin kafka rereplicate
is hitting nil panics on some workflows, and this appears to be the source: a nil mutablestate builder.I've added it here and am running tests and it may be the fix, but I am NOT yet sure:
An example of the panic:
This appears to be a nil mutable state builder at service/history/execution/history_builder.go:345, which looks like it can only come from
HistoryBuilder
instances created byNewHistoryBuilderFromEvents
because it doesn't set that field.I have not yet figured out why that function doesn't set that field though.