Skip to content

[BACK-3478] Add email notifications work system processors.#896

Open
lostlevels wants to merge 10 commits intomasterfrom
jimmy-device-email-notifications
Open

[BACK-3478] Add email notifications work system processors.#896
lostlevels wants to merge 10 commits intomasterfrom
jimmy-device-email-notifications

Conversation

@lostlevels
Copy link
Contributor

No description provided.

Copy link
Contributor

@darinkrauss darinkrauss left a comment

Choose a reason for hiding this comment

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

Some thoughts...

@@ -0,0 +1,129 @@
package claimaccount
Copy link
Contributor

Choose a reason for hiding this comment

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

In order to fit in with the other platform and work implementations, how about we move this to notifications/work/users/claim. And, for the others, notifications/work/users/connections/new and notifications/work/users/connections/issues.

Copy link
Contributor Author

@lostlevels lostlevels Jan 12, 2026

Choose a reason for hiding this comment

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

I went with a middle ground of

  • notifications/work/claims
    *notifications/work/connections/requests
  • notifications/work/connections/issues

Not a huge fan of packages where the parent packages are empty. IMO some package named connectionissues gives me pretty good idea of what it deals with, in the same way package stringutil does. When it gets to connections => subcategory is where things can start getting hairy if then sub-subcategories are added.

Copy link
Contributor

@darinkrauss darinkrauss left a comment

Choose a reason for hiding this comment

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

A number of quick, minor changes. Also, I didn't highlight every instance, but please replace all fmt.Errorf with errors.Newf or errors.Wrapf, as appropriate. Otherwise, looks good.


type Metadata struct {
ClinicID string `json:"clinicId,omitempty"`
UserId string `json:"userId,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Uppercase ID per Golang convention:

Suggested change
UserId string `json:"userId,omitempty"`
UserID string `json:"userId,omitempty"`

@darinkrauss
Copy link
Contributor

Also, it looks like the build is failing. Try running make generate build test and, assuming that works, commit the changes. There are probably minor formatting changes.

darinkrauss
darinkrauss previously approved these changes Jan 28, 2026
Copy link
Contributor

@darinkrauss darinkrauss left a comment

Choose a reason for hiding this comment

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

LGTM, just one question out of curiosity.

script:
- export TIMING_CMD='time -p'
- make plugins-visibility-${PLUGINS_VISIBILITY} && make ci
- make "plugins-visibility-${PLUGINS_VISIBILITY}" && make ci
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this to silence some linter warning or another?

@lostlevels lostlevels force-pushed the jimmy-device-email-notifications branch from bd00c01 to a0e93d5 Compare February 11, 2026 17:58
Copy link
Contributor

@ewollesen ewollesen left a comment

Choose a reason for hiding this comment

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

Aside from not seeing a matching TidepoolApi PR, all my comments are non-blocking.

Nice work.

connrequests "github.com/tidepool-org/platform/notifications/work/connections/requests"
)

func NotificationsRoutes() []dataService.Route {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't see the matching PR to TidepoolApi for these endpoints. Have I missed something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are internal routes, do we usually add those?


var data claims.Metadata
if err := request.DecodeRequestBody(req.Request, &data); err != nil {
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit

Suggested change
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
responder.Error(http.StatusBadRequest, err)


var data connrequests.Metadata
if err := request.DecodeRequestBody(req.Request, &data); err != nil {
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
responder.Error(http.StatusBadRequest, err)


var data connissues.Metadata
if err := request.DecodeRequestBody(req.Request, &data); err != nil {
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
request.MustNewResponder(res, req).Error(http.StatusBadRequest, err)
responder.Error(http.StatusBadRequest, err)

return errors.Wrap(err, "unable to create clinics client")
}
s.clinicsClient = &clnt
s.clinicsClient = clnt
Copy link
Contributor

Choose a reason for hiding this comment

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

👍🏻 nice update

// to group related claim account notifications together so they can all be
// deleted if the condition to send them is no longer active. For example, if a
// user has already claimed their account but there is a pending notification
// that hasn't been processed yetm the processor should delete all work items
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// that hasn't been processed yetm the processor should delete all work items
// that hasn't been processed yet the processor should delete all work items

}
create := newWorkCreate(whenToSend, metadata)
if groupID := pointer.DefaultString(create.GroupID, ""); groupID != "" {
// Delete any other work items with the same group id because if a new reminder is added, any older ones would be too early since the last reminder of the same group id.
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, so what happens if we add a reminder with a WhenToSend of 7 days... Then an hour later we add a reminder with a WhenToSend of 3 days.

In that case, the existing reminder isn't too early, as your comment states.

Maybe you meant to say something like "we maintain only a single reminder (per GroupID) at a time, and the last reminder added to the system wins"?

return notifications.NewFailingResult(err, wrk)
}
if patient == nil {
return notifications.NewFailingResult(errors.Newf(`unable to find patient with userId "%v"`, data.UserID), wrk)
Copy link
Contributor

Choose a reason for hiding this comment

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

including the clinicId here too is probably useful, since a user could be a member of multiple clinics. Seeing this message, I would look for patient records with that user id, and I might find 1 or more and scratch my head as to why it couldn't be found (not realizing that it's supposed to be scoped to a specific clinic)

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.

3 participants