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

Fix panic when Daily Summary is nil for a user #199

Merged
merged 2 commits into from
Dec 2, 2020

Conversation

larkox
Copy link
Contributor

@larkox larkox commented Nov 23, 2020

Summary

There seems to be a panic in master that happens when the daily summary settings are set to nil. This should never happen, but maybe a weird status in the system is triggering this.

This PR makes sure the daily summary setting is set by adding a default in every point it is present.

Another solution could be remove the indirection and trust the go defaults.

Ticket Link

None

@larkox larkox added 2: Dev Review Requires review by a core committer 3: QA Review Requires review by a QA tester labels Nov 23, 2020
@codecov-io
Copy link

codecov-io commented Nov 23, 2020

Codecov Report

Merging #199 (2dd2b00) into master (50beb11) will decrease coverage by 0.07%.
The diff coverage is 11.11%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #199      +/-   ##
==========================================
- Coverage   23.05%   22.97%   -0.08%     
==========================================
  Files          64       64              
  Lines        2316     2324       +8     
==========================================
  Hits          534      534              
- Misses       1703     1709       +6     
- Partials       79       81       +2     
Impacted Files Coverage Δ
server/mscalendar/daily_summary.go 42.27% <11.11%> (-2.95%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 50beb11...2dd2b00. Read the comment docs.

Copy link
Contributor

@jfrerich jfrerich left a comment

Choose a reason for hiding this comment

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

Non-block suggestion. OTW, LGTM

@@ -75,6 +83,14 @@ func (m *mscalendar) SetDailySummaryEnabled(user *User, enable bool) (*store.Dai
return nil, err
}

if user.Settings.DailySummary == nil {
user.Settings.DailySummary = &store.DailySummaryUserSettings{
Copy link
Contributor

Choose a reason for hiding this comment

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

LGTM. Wondering if it would be worth returning this object from a small function since it is used 3 times?

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 thought so, but since the object is being used in the store and in the main package, I thought it would create circular dependencies unless we store it in the store. And the store does not seem the best place for this.

Copy link
Contributor

Choose a reason for hiding this comment

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

1/5 I agree with Jason to make it into a function. If the store is the only place it can go, then I suppose that's where it has to go.

Copy link
Contributor

@mickmister mickmister left a comment

Choose a reason for hiding this comment

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

LGTM, though I have one request to move the struct initialization into a function

@@ -75,6 +83,14 @@ func (m *mscalendar) SetDailySummaryEnabled(user *User, enable bool) (*store.Dai
return nil, err
}

if user.Settings.DailySummary == nil {
user.Settings.DailySummary = &store.DailySummaryUserSettings{
Copy link
Contributor

Choose a reason for hiding this comment

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

1/5 I agree with Jason to make it into a function. If the store is the only place it can go, then I suppose that's where it has to go.

@mickmister mickmister removed the 2: Dev Review Requires review by a core committer label Nov 30, 2020
Copy link

@DHaussermann DHaussermann left a comment

Choose a reason for hiding this comment

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

Tested and passed

  • Tested affected user and saw crash resolved
  • Regression tested disconnect and authentication
  • No issues found

LGTM!

@DHaussermann DHaussermann added 4: Reviews Complete All reviewers have approved the pull request and removed 3: QA Review Requires review by a QA tester labels Dec 1, 2020
@DHaussermann
Copy link

Thanks @larkox for this fix.

Could you please merge to master so I can pull this into #183 this issue seems to be complicating testing for the Slack Attachment PR.

@larkox larkox merged commit a488054 into mattermost:master Dec 2, 2020
@hanzei hanzei added this to the v1.1.0 milestone Dec 2, 2020
@mickmister mickmister mentioned this pull request Oct 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4: Reviews Complete All reviewers have approved the pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants