Update App Notifications

[AlexTugarev]

Description

Dismiss Usage Limit notifications automatically on resolution, e.g. on increase of Usage Limit.

Related Issue(s)

Fixes #12547

How to test

• Have 2 accounts on a team with UB enabled.
• Decrease usage limit and drive into the limit notification.
• Increase the spending limit on one account.
• See the notification is dismissed for both accounts.

Release Notes

Dismiss Usage Limit notifications automatically.

Documentation

Werft options:

• /werft with-preview
• /werft with-payment

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-at-update-notifications.2
(with .werft/ from main)

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-at-update-notifications.3
(with .werft/ from main)

[jldec]

/werft run

👍 started the job as gitpod-build-at-update-notifications.4
(with .werft/ from main)

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-at-update-notifications.7
(with .werft/ from main)

[AlexTugarev]

@jldec, please have a look. 🙏🏻
(Hopefully, the latest build will succeed 🤞🏻 )

[svenefftinge]

tbh, it seems a bit overkill to roll out push events for this. @jldec why do we need to show the limit everywhere in the dashboard? Would it not be sufficient to check and display the limit on workspace-start?

[jldec]

@svenefftinge, @AlexTugarev, the idea behind a global dashboard notification from the start was that this message is really intended for team owners who may not be starting workspaces all the time. (We also envisaged email notifications at some (80%) threshold before the limit is reached.)

If the notification mechanism is really expensive (implementation cost, complexity), we could pull back and ship just the notification/error on start workspace for now, but if we have something that works globally, I believe users would prefer that because it makes the out-of-credits status much clearer.

[svenefftinge]

this message is really intended for team owners who may not be starting workspaces all the time

I don't think people who don't start workspaces hang out on the dashboard. They would get nudged by developers who see the information when starting a workspace.

[jldec]

@svenefftinge Maybe I'm nitpicking, but the UX of a dashboard notification does feel superior. Happy to roll-back if you think the implementation or complexity cost is not worth it.

Error-on-start only (no dashboard notification):

• developer gets error on workspace start
• contacts team owner
• team owner first confirms error by starting a workspace
• team owner sees error and confirms that it is because "usage limit exceeded"

Dashboard notification

• any team member sees error (on workspace start or in dashboard)
• contacts team owner
• team owner immediately sees "usage limit exceeded" in dashhboard - no additional confirmation required

[jldec]

Thank you @AlexTugarev
LGTM - tested as described in PR description and the notification works as advertised.

/hold in case you decide to pull back, based on discussion with @svenefftinge.

[svenefftinge]

Anyone should see the status of usage vs limits when looking at the billing page - no need to start a workspace. But I shared my concerns and don't want to further block this if you think it's good.

[geropl]

Anyone should see the status of usage vs limits when looking at the billing page - no need to start a workspace. But I shared my concerns and don't want to further block this if you think it's good.

I feel having (reactive) notifications like this can lift the UX to a new level, and I think we should aim for that. Notifications like this have been requested for a couple of usecases and the abstraction and mechanism solves the it nicely. Treating the paywall as a first "test driver" felt like the natural choice.

@AlexTugarev I left some cleanup comments, and a potential follow-up, but besides: Looks good to go! 👍

[AlexTugarev]

Thanks for the review, @geropl! Changes applied. Build is running...

[AlexTugarev]

Fixed compile errors after rebase merge conflicts.

[AlexTugarev]

Typechecking Werft Typescript files
STDOUT: platform-delete-preview-environment.ts(3,10): error TS2305: Module '"./util/preview"' has no exported member 'HarvesterPreviewEnvironment'.
platform-delete-preview-environment.ts(3,39): error TS2305: Module '"./util/preview"' has no exported member 'PreviewEnvironment'.

looks unrelated. updated again.

[AlexTugarev]

/hold cancel