chore: remove notifications experiment #14869
Conversation
3148702 to
6add98f
Compare
|
@dannykopping thanks for calling out that note. We should ship as is and revisit this before the next release. I'd opt to keep the defaults with a note in the docs rather than introduce friction in backward compatibility. To improve visibility, I can link to this PR in the release notes for 2.16.0. We get a lot of negative feedback on the difficulty of reverting upgrades, and it'd be unfortunate for a downgrade to override their settings. Can we merge this ASAP so I can pull it into the release branch? Just whenever you all are online. (cc @mtojek) |
| @@ -49,7 +49,7 @@ func NewReportGenerator(ctx context.Context, logger slog.Logger, db database.Sto | |||
| return nil | |||
| } | |||
|
|
|||
| err = reportFailedWorkspaceBuilds(ctx, logger, db, enqueuer, clk) | |||
| err = reportFailedWorkspaceBuilds(ctx, logger, tx, enqueuer, clk) | |||
There was a problem hiding this comment.
Passing the main db object through caused a deadlock; we need to pass the transaction-scoped db object instead.
Signed-off-by: Danny Kopping <[email protected]>
Signed-off-by: Danny Kopping <[email protected]>
Signed-off-by: Danny Kopping <[email protected]>
…rovisionerDaemon Signed-off-by: Danny Kopping <[email protected]>
Signed-off-by: Danny Kopping <[email protected]>
593c5a0 to
0107ad1
Compare
|
I've added the beta badge:
|
Signed-off-by: Danny Kopping <[email protected]>
5bffd26 to
0aa6d7b
Compare
| @@ -148,11 +148,12 @@ const DeploymentSettingsNavigation: FC<DeploymentSettingsNavigationProps> = ({ | |||
| Users | |||
| </SidebarNavSubItem> | |||
| )} | |||
| {experiments.includes("notifications") && ( | |||
| <Stack direction={"row"} alignItems={"center"} css={{ gap: 0 }}> | |||
There was a problem hiding this comment.
Nit: When passing string values directly you can pass the value directly without the brackets:
direction="row"
|
I tried to QA this locally, but I don't see the option in the sidebar when starting the server without any experiments set. Is it expected? I'm not sure how we are handling beta features tho. |
Signed-off-by: Danny Kopping <[email protected]>
Signed-off-by: Danny Kopping <[email protected]>
Notifications have proved stable in the [mainline release of v2.15](https://github.com/coder/coder/releases/tag/v2.15.0), and in preparation for v2.16 we're moving this to stable. (cherry picked from commit 11f7b1b)
- [x] #14869 - [x] #14778 - [x] #14883 Addition to resolve flake: - [x] #14875 --------- Co-authored-by: Danny Kopping <[email protected]> Co-authored-by: Garrett Delfosse <[email protected]> Co-authored-by: Ben Potter <[email protected]> Co-authored-by: Spike Curtis <[email protected]>
Notifications have proved stable in the mainline release of v2.15, and in preparation for v2.16 we're moving this to stable.
Note:
Assuming a config which relies on the defaults for notifications settings, customers will now start seeing logs like this (assuming they don't have an open SMTP server on localhost):
This occurs because the default notification method is set as
smtpinCODER_NOTIFICATIONS_METHOD, and other defaults are configured (CODER_NOTIFICATIONS_EMAIL_SMARTHOSTandCODER_NOTIFICATIONS_EMAIL_HELLO).This is not harmful, but it is avoidable. We'd have to remove the default values for
CODER_NOTIFICATIONS_EMAIL_SMARTHOSTandCODER_NOTIFICATIONS_EMAIL_HELLO, and detect their absence, and log a warning with a link to the docs.Effectively it amounts to the same thing, but it's a little more user-friendly.
The challenge with this approach, though, is it might remove some actually useful default values for customers. We could cover this in release notes, but it weakens our backwards-compatibility posture. It's not strictly a break, but it could cause unintended behaviour if operators blindly upgrade without reading the notes (everybody reads the release notes, right? RIGHT?) and they rely on these defaults.
I think a good middleground could be to mention the docs in the above error log. Then, when we implement #14644, we remove the default SMTP values and set a
nonemethod by default.In retrospect I should've tried to find a way to not define any defaults here, but we live and learn.