Makefile (1)

6-6: Notifications correctly integrated into build/docker service list

Adding notifications to SERVICES ensures it’s built and containerized alongside other services via all, $(DOCKERS), and publish targets. Once the notifications HTTP API and OpenAPI spec are stable, consider adding it to TEST_API_SERVICES and defining a test_api_notifications target so it benefits from the same contract-testing harness as other APIs.

notifications/invitations.go (1)

10-21: Invitation model and repository interface are well-scoped

The Invitation struct captures just the data needed for notifications, and the repository contract is small and context-aware. The db tags make sense given the likely column names. If you expect consumers to distinguish “not found” from other failures frequently, consider standardizing on a shared sentinel (e.g., ErrInvitationNotFound) from this package or the Postgres adapter to simplify error handling across callers.

notifications/users.go (1)

10-33: Clear minimal user/domain models and repository contracts

The User/Domain structs and their repositories are lean and match the “minimal data for notifications” goal. Using plain field names without tags is fine as long as DB columns align; for divergent schemas you can mirror the approach taken in Invitation with explicit db tags. No issues from a domain/API perspective.

docker/templates/invitation-sent-email.tmpl (1)

1-28: Invitation email template is clean; align data model and consider minor UX tweaks

The HTML structure and placeholders (.Subject, .Header, .User, .Content, .Footer) look good for a generic invitation email. Please double-check that the emailer’s data model uses these exact field names when executing the template to avoid runtime errors. As optional polish, you might later add a short preheader line and stronger accessibility cues (e.g., more semantic headings or alt text if images are introduced).

notifications/api/transport.go (1)

25-28: LoggingErrorEncoder logs but doesn't write an HTTP response.

The function accepts http.ResponseWriter but only logs the error without writing any response. This could leave clients without feedback. If this is intentional (e.g., used in a chain where another encoder writes the response), consider documenting that behavior. Otherwise, write an appropriate error response.

If the intent is to both log and respond, consider:

 // LoggingErrorEncoder is an HTTP error encoder that logs the error.
-func LoggingErrorEncoder(logger *slog.Logger, w http.ResponseWriter, err error) {
+func LoggingErrorEncoder(logger *slog.Logger, w http.ResponseWriter, err error) {
 	logger.Error("error encoding response", slog.Any("error", err))
+	http.Error(w, "internal server error", http.StatusInternalServerError)
 }

Alternatively, if this is meant to be composed with another encoder, document that the caller is responsible for writing the response.

notifications/service.go (1)

38-73: Unify invitee/inviter name fallback logic between the two handlers

sendInvitationSent and sendInvitationAccepted derive inviteeName/inviterName with slightly different fallbacks (only the accepted path falls back to "A user" for the invitee). For edge cases where both username and email are empty, InvitationSent can end up with an empty inviteeName while InvitationAccepted will not.

Consider extracting a small helper to derive a display name from (username, email) and using it in both handlers, with a consistent final fallback like "A user". This reduces duplication and avoids subtle behavioral differences between notification types.

Also applies to: 75-110

notifications/events/consumer.go (1)

31-55: Remove debug fmt.Println and optionally log unsupported operations via the logger

There’s a stray fmt.Println("operation:", operation) in the hot path, and unknown operations are silently ignored. Both make debugging/observability harder and bypass the structured logger.

You can lean on logger instead and warn on unsupported operations:

@@ func Handle(svc notifications.Service, userRepo notifications.UserRepository, domainRepo notifications.DomainRepository, invitationRepo notifications.InvitationRepository, logger *slog.Logger) handleFunc {
-		return func(ctx context.Context, event events.Event) error {
+		return func(ctx context.Context, event events.Event) error {
@@
-		operation, ok := data["operation"].(string)
-		if !ok {
-			logger.Error("missing operation in event")
-			return nil
-		}
-		fmt.Println("operation:", operation)
-
-		switch operation {
+		operation, ok := data["operation"].(string)
+		if !ok {
+			logger.Error("missing operation in event")
+			return nil
+		}
+
+		switch operation {
@@
-		case invitationAccept:
-			return handleInvitationAccepted(ctx, data, svc, userRepo, domainRepo, invitationRepo, logger)
-		default:
-			return nil
+		case invitationAccept:
+			return handleInvitationAccepted(ctx, data, svc, userRepo, domainRepo, invitationRepo, logger)
+		default:
+			logger.Warn("unsupported operation in event",
+				slog.String("operation", operation),
+			)
+			return nil
 		}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

notifications/postgres/invitations.go (1)

28-39: Distinguish sql.ErrNoRows from other database errors.

The error handling wraps all StructScan errors as ErrNotFound, which masks connection failures, query errors, etc. This was flagged in a previous review.

cmd/notifications/main.go (1)

184-187: Propagate g.Wait() failures via a non-zero exit code.

When g.Wait() returns an error, exitCode remains 0, causing the process to exit successfully despite runtime failures. This was flagged in a previous review.

docker/.env (1)

557-573: Invitation email env vars still misaligned with notifications config and have quoting issues

The invitation email block here still uses:

• SMQ_INVITATION_SENT_EMAIL_TEMPLATE / SMQ_INVITATION_ACCEPTED_EMAIL_TEMPLATE
• Per-invitation *_HOST/PORT/USERNAME/PASSWORD
• Unquoted SMQ_INVITATION_*_EMAIL_FROM_NAME=SuperMQ Team values (spaces require quotes)

while the notifications service reads SMQ_NOTIFICATIONS_INVITATION_SENT_TEMPLATE / SMQ_NOTIFICATIONS_INVITATION_ACCEPTED_TEMPLATE and email.Config only consumes the shared SMQ_EMAIL_* vars. This means template paths set here won’t be used, and the extra host/port/credentials vars are effectively dead config.

Please align the template variable names with what cmd/notifications/main.go expects, remove unused invitation-specific host/port/credential vars, and quote the FROM_NAME values, as suggested in the earlier review.

cmd/notifications/main.go (1)

189-192: Consider inlining or documenting the purpose of newService.

This wrapper currently just calls notifications.NewService. If it's a placeholder for future middleware (logging, tracing), consider adding a comment. Otherwise, it could be inlined.

notifications/emailer/emailer.go (1)

20-36: Wrap constructor errors with context for easier diagnosis

New currently returns raw errors from email.New, which can make debugging harder once multiple email configs exist. Consider wrapping them with context:

 func New(invitationSentConfig, invitationAcceptedConfig *email.Config) (notifications.Emailer, error) {
 	invitationSentAgent, err := email.New(invitationSentConfig)
 	if err != nil {
-		return nil, err
+		return nil, fmt.Errorf("creating invitation-sent email agent: %w", err)
 	}
 
 	invitationAcceptedAgent, err := email.New(invitationAcceptedConfig)
 	if err != nil {
-		return nil, err
+		return nil, fmt.Errorf("creating invitation-accepted email agent: %w", err)
 	}

This keeps call sites clearer when one of the two setups fails.

notifications/events/consumer.go (2)

39-53: Remove fmt.Println and prefer structured logging / debug logs

fmt.Println("operation:", operation) bypasses your structured logging and will spam stdout in production. Consider removing it or replacing it with a debug log, e.g.:

-		fmt.Println("operation:", operation)
-
 	switch operation {

or:

logger.Debug("processing notification event", slog.String("operation", operation))

if you still need traceability.

---

57-120: Re-evaluate swallowing repository/email errors (events get effectively dropped)

In both handleInvitationSent and handleInvitationAccepted, all failures in user/domain/invitation lookups and in svc.SendNotification are logged but return nil. If the subscriber treats nil as “message successfully handled”, these events will be acknowledged and never retried, even on transient DB/email outages.

If the intent is at-least-once delivery, consider:

• Returning non-nil errors for transient failures (DB/email) so the subscriber can retry, and
• Only returning nil for clearly unrecoverable cases (e.g., permanently bad payload / missing fields).

Please confirm this behavior matches the expected semantics of pkg/events.Subscriber in this service.

Also applies to: 122-195

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cmd/notifications/main.go (1)

186-196: Set exitCode on errgroup failure.

When g.Wait() returns an error (e.g., HTTP server failure or signal handler error), the error is logged but exitCode remains 0. This causes the process to exit successfully despite failures, which can mislead supervisors and monitoring systems.

Apply this diff to propagate failures:

 	if err := g.Wait(); err != nil {
 		logger.Error(fmt.Sprintf("%s service terminated: %s", svcName, err))
+		exitCode = 1
 	}

cmd/notifications/main.go (1)

199-201: Consider removing unnecessary wrapper.

The newService function is a thin wrapper around notifications.NewService without additional logic. Consider calling notifications.NewService directly at line 148 to reduce indirection, unless this wrapper is intended for future extensibility or testing.

notifications/service.go (1)

52-114: Consider refactoring to reduce code duplication.

The sendInvitationSent and sendInvitationAccepted methods share significant structural similarity:

• Domain name normalization logic (lines 58-62 and 90-94)
• Notifier iteration and error handling (lines 70-79 and 102-111)

Consider extracting a helper method to handle the common notification dispatch logic, parameterized by the recipient email and log message.

notifications/emailer/emailer.go (1)

56-116: Consider refactoring to reduce duplication and improve consistency.

The two email methods share significant logic:

• Domain name fallback (lines 70-73 and 101-104 are identical)
• Subject prefix handling (lines 76-78 and 107-109 are identical)
• Name fallback patterns with slight variations

Additionally, there's an inconsistency: sendInvitationSentEmail provides "A user" fallback for the inviter (lines 66-68), while sendInvitationAcceptedEmail provides "A user" fallback for the invitee (lines 92-94) but not for the inviter.

Consider extracting common logic and ensuring consistent fallback behavior across both methods.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cmd/notifications/main.go (1)

194-196: Propagate g.Wait() failures via a non-zero exit code.

When g.Wait() returns an error, the service logs it but exits with code 0 (success). This misleads supervisors and monitoring systems. Set exitCode = 1 on error.

 	if err := g.Wait(); err != nil {
 		logger.Error(fmt.Sprintf("%s service terminated: %s", svcName, err))
+		exitCode = 1
 	}

docker/.env (1)

557-574: Previous review concerns about template env var naming and quoting still apply.

The template env var names (SMQ_INVITATION_SENT_EMAIL_TEMPLATE, SMQ_INVITATION_ACCEPTED_EMAIL_TEMPLATE) still don't match what cmd/notifications/main.go reads (SMQ_NOTIFICATIONS_INVITATION_SENT_TEMPLATE, SMQ_NOTIFICATIONS_INVITATION_ACCEPTED_TEMPLATE). Additionally, the FROM_NAME values on lines 563 and 572 should be quoted since they contain spaces.

notifications/api/transport.go (1)

25-28: LoggingErrorEncoder only logs but does not write an HTTP response.

This function logs the error but doesn't write a status code or body to the ResponseWriter. If this is intended to be used as an error encoder (e.g., for go-kit or similar frameworks), callers will receive an empty response. Either add HTTP response writing or document that this is a supplementary logger meant to be called alongside another encoder.

 // LoggingErrorEncoder is an HTTP error encoder that logs the error.
 func LoggingErrorEncoder(logger *slog.Logger, w http.ResponseWriter, err error) {
 	logger.Error("error encoding response", slog.Any("error", err))
+	w.Header().Set("Content-Type", "application/json")
+	w.WriteHeader(http.StatusInternalServerError)
 }

notifications/postgres/domains.go (1)

28-37: Error handling wraps all errors as ErrNotFound, masking database connection issues.

The current implementation wraps every error (including connection failures, timeouts, etc.) with repoerr.ErrNotFound. This can mask real infrastructure issues. Consider checking for sql.ErrNoRows specifically to distinguish between "not found" and actual errors.

 func (repo *domainRepository) RetrieveByID(ctx context.Context, id string) (notifications.Domain, error) {
 	query := `SELECT id, name FROM domains WHERE id = $1`

 	var domain notifications.Domain
 	if err := repo.db.QueryRowxContext(ctx, query, id).StructScan(&domain); err != nil {
+		if errors.Is(err, sql.ErrNoRows) {
+			return notifications.Domain{}, errors.Wrap(repoerr.ErrNotFound, err)
+		}
-		return notifications.Domain{}, errors.Wrap(repoerr.ErrNotFound, err)
+		return notifications.Domain{}, errors.Wrap(repoerr.ErrViewEntity, err)
 	}

 	return domain, nil
 }

This requires adding "database/sql" to imports.

cmd/notifications/main.go (2)

113-117: Tracer shutdown may use an already-cancelled context.

When cancel() is called (e.g., on signal), ctx becomes cancelled before the deferred shutdown runs. This could cause tp.Shutdown(ctx) to fail immediately. Consider using context.Background() with a timeout for graceful shutdown.

 	defer func() {
-		if err := tp.Shutdown(ctx); err != nil {
+		shutdownCtx, shutdownCancel := context.WithTimeout(context.Background(), 5*time.Second)
+		defer shutdownCancel()
+		if err := tp.Shutdown(shutdownCtx); err != nil {
 			logger.Error(fmt.Sprintf("error shutting down tracer provider: %s", err))
 		}
 	}()

This requires adding "time" to imports.

---

199-201: Consider inlining the newService wrapper function.

This function is a trivial pass-through to notifications.NewService. Unless there's a plan to add middleware or additional setup, consider calling notifications.NewService directly at line 148 for clarity.

notifications/service.go (1)

14-28: Config fields are defined but never used in the service.

The Config struct defines InvitationSentTemplate, InvitationAcceptedTemplate, DefaultSubjectPrefix, and DefaultFooter, but these fields are never accessed in the service implementation. The config field is stored in the service struct (line 27) but never utilized.

If these configuration values are intended for the emailer.Config instead, consider removing them from this struct to avoid confusion, or add the logic to pass them to the notifiers.

notifications/events/consumer.go (1)

6-8: Remove unused fmt import after removing debug print.

The fmt package (line 8) is only used for the debug fmt.Println statement. After removing that line, this import should also be removed.

notifications/emailer/emailer.go (1)

45-54: Consider returning nil for unsupported types to align with service layer.

The emailer returns an error for unsupported notification types (line 52), but the service.SendNotification method returns nil with a warning log for unknown types. This inconsistency means if a new notification type is added to the service but not to the emailer, the service will log "failed to send notification via notifier" errors even though this is expected behavior.

Consider returning nil with logging instead:

 	default:
-		return fmt.Errorf("unsupported notification type: %s", notification.Type.String())
+		// Unsupported types are silently ignored by this notifier
+		return nil
 	}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

users/emailer/emailer.go (1)

66-76: Consider using email config's FromName instead of hardcoded footer.

The implementations correctly format subjects and content for invitation emails. However, the footer is hardcoded as "SuperMQ Team" (lines 69 and 75), which could be inconsistent if the email configuration specifies a different FromName.

Consider passing the FromName from the respective email config to maintain consistency:

 func (e *emailer) SendInvitation(to []string, inviteeName, inviterName, domainName, roleName string) error {
 	subject := fmt.Sprintf("You've been invited to join %s", domainName)
 	content := fmt.Sprintf("%s has invited you to join %s as %s.", inviterName, domainName, roleName)
-	return e.invitationAgent.Send(to, "", subject, "", inviteeName, content, "SuperMQ Team")
+	return e.invitationAgent.Send(to, "", subject, "", inviteeName, content, e.invitationAgent.conf.FromName)
 }

 func (e *emailer) SendInvitationAccepted(to []string, inviterName, inviteeName, domainName, roleName string) error {
 	subject := fmt.Sprintf("%s accepted your invitation to %s", inviteeName, domainName)
 	content := fmt.Sprintf("%s has accepted your invitation to join %s as %s.", inviteeName, domainName, roleName)
-	return e.invitationAcceptedAgent.Send(to, "", subject, "", inviterName, content, "SuperMQ Team")
+	return e.invitationAcceptedAgent.Send(to, "", subject, "", inviterName, content, e.invitationAcceptedAgent.conf.FromName)
 }

Note: This assumes Agent.conf is exported or accessible. If not, consider storing the FromName values separately during emailer construction.

users/events/consumer.go (1)

102-120: Extract name normalization to a helper function to reduce duplication.

The name normalization logic is duplicated in handleInvitationAccepted. Additionally, there's an inconsistency: inviteeName can end up empty if Email is also empty, while inviterName has a final fallback to "A user".

Consider extracting this to a helper:

func normalizeName(user users.User, defaultName string) string {
	name := strings.TrimSpace(user.FirstName + " " + user.LastName)
	if name == "" {
		name = user.Credentials.Username
	}
	if name == "" {
		name = user.Email
	}
	if name == "" {
		name = defaultName
	}
	return name
}

Then use it consistently in both handlers:

-	inviteeName := invitee.FirstName + " " + invitee.LastName
-	if inviteeName == " " || inviteeName == "" {
-		inviteeName = invitee.Credentials.Username
-	}
-	if inviteeName == "" {
-		inviteeName = invitee.Email
-	}
-
-	inviterName := inviter.FirstName + " " + inviter.LastName
-	if inviterName == " " || inviterName == "" {
-		inviterName = inviter.Credentials.Username
-	}
-	if inviterName == "" {
-		inviterName = inviter.Email
-	}
-	if inviterName == "" {
-		inviterName = "A user"
-	}
+	inviteeName := normalizeName(invitee, invitee.Email)
+	inviterName := normalizeName(inviter, "A user")

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

users/events/consumer.go (2)

111-137: Make display-name fallback rules consistent across invitee/inviter and handlers

The name normalization logic differs between handlers:

• In handleInvitationSent, inviteeName never falls back to "A user", but inviterName does.
• In handleInvitationAccepted, inviteeName does fall back to "A user", but inviterName does not.

This asymmetry can lead to inconsistent email content depending on which side of the flow you’re in. Consider extracting a shared helper (e.g. displayName(u users.User, defaultName string) string) that applies the same fallback order everywhere, such as:

1. FirstName + " " + LastName (if not just " ").
2. Credentials.Username.
3. Email.
4. Final default (e.g. "A user").

Then use it for both invitee and inviter in both handlers.

-	inviteeName := invitee.FirstName + " " + invitee.LastName
-	if inviteeName == " " || inviteeName == "" {
-		inviteeName = invitee.Credentials.Username
-	}
-	if inviteeName == "" {
-		inviteeName = invitee.Email
-	}
+	inviteeName := displayName(invitee, "A user")
...
-	inviterName := inviter.FirstName + " " + inviter.LastName
-	if inviterName == " " || inviterName == "" {
-		inviterName = inviter.Credentials.Username
-	}
-	if inviterName == "" {
-		inviterName = inviter.Email
-	}
-	if inviterName == "" {
-		inviterName = "A user"
-	}
+	inviterName := displayName(inviter, "A user")

Also applies to: 190-216

---

139-151: Validate recipient email before invoking the emailer

Both handlers call the emailer with a single-recipient slice built from potentially empty email fields:

• SendInvitation([]string{invitee.Email}, ...)
• SendInvitationAccepted([]string{inviter.Email}, ...)

If those addresses are empty, you’ll attempt to send to "", which most email backends will reject and which obscures the real problem (missing email on the user).

Add a guard before sending in each handler: trim/verify the email, log a warning with the relevant user ID if it’s empty, and return nil instead of calling the emailer. This is exactly what earlier review feedback suggested.

-	// Send invitation email
-	if err := emailer.SendInvitation([]string{invitee.Email}, inviteeName, inviterName, domainName, roleName); err != nil {
+	if strings.TrimSpace(invitee.Email) == "" {
+		logger.Warn("invitee has no email address",
+			slog.String("user_id", inviteeUserID),
+		)
+		return nil
+	}
+	// Send invitation email
+	if err := emailer.SendInvitation([]string{invitee.Email}, inviteeName, inviterName, domainName, roleName); err != nil {
@@
-	// Send invitation accepted email
-	if err := emailer.SendInvitationAccepted([]string{inviter.Email}, inviterName, inviteeName, domainName, roleName); err != nil {
+	if strings.TrimSpace(inviter.Email) == "" {
+		logger.Warn("inviter has no email address",
+			slog.String("user_id", invitedBy),
+		)
+		return nil
+	}
+	// Send invitation accepted email
+	if err := emailer.SendInvitationAccepted([]string{inviter.Email}, inviterName, inviteeName, domainName, roleName); err != nil {

Also applies to: 218-230

users/events/consumer_test.go (3)

22-27: Avoid using a zero-value testing.T in GenerateUUID calls

Passing &testing.T{} into testsutil.GenerateUUID is unidiomatic and relies on testing.T working correctly in a zero value. Prefer generating these IDs inside each test using the real *testing.T (e.g. id := testsutil.GenerateUUID(t)) or introducing a UUID helper that doesn’t depend on testing.T.

---

42-199: Strengthen mock expectations and context handling in table-driven tests

Right now the cases only assert that handler.Handle returns nil; they don’t verify that RetrieveByID and SendInvitation are called (or not called) as intended, and the mocks use fresh context.Background() instances as arguments.

Consider:

• Using a shared ctx := context.Background() per test and passing that both to repo.On(...) and handler.Handle(ctx, ...), or using mock.Anything for the context argument.
• Setting expectations with .Once() / .Times(n) and finishing each subtest with repo.AssertExpectations(t) and emailer.AssertExpectations(t) (and/or AssertCalled / AssertNotCalled) to actually validate behavior per case.

This will make the tests much more effective at catching regressions in repo/emailer usage.

---

201-350: Reduce duplication between “sent” and “accepted” test tables

TestHandleInvitationSent and TestHandleInvitationAccepted repeat a lot of setup (users, mocks, logger, cases, and subtest loop structure). Extracting common scaffolding into helpers (e.g. a shared factory for cases + runner that injects the specific email method name) would reduce duplication and make it easier to add new scenarios consistently.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

users/events/consumer.go (2)

111-138: Validate invitee email and harmonize fallback logic.

Two issues in the name normalization:

1. Empty email validation: If invitee.Email is empty (line 142), the notification will be sent with an empty recipient, causing it to fail.

2. Inconsistent fallback: inviterName falls back to "A user" (lines 127-129), but inviteeName does not. This inconsistency differs from handleInvitationAccepted where inviteeName has the fallback but inviterName doesn't.

Apply this diff to add email validation:

 	if inviteeName == "" {
 		inviteeName = invitee.Email
 	}
+	if inviteeName == "" {
+		inviteeName = "A user"
+	}
 
 	inviterName := inviter.FirstName + " " + inviter.LastName

And add validation before sending:

+	if invitee.Email == "" {
+		logger.Warn("invitee has no email address",
+			slog.String("user_id", inviteeUserID),
+		)
+		return nil
+	}
+
 	// Send invitation notification
 	notificationData := users.NotificationData{

---

201-228: Add inviter email validation and fallback for inviterName.

Two issues in the name normalization:

1. Missing fallback for inviterName: Unlike handleInvitationSent, inviterName doesn't fall back to "A user" when all other values are empty (line 219). Meanwhile, inviteeName has the fallback (lines 209-211). This is the reverse of the inconsistency in handleInvitationSent.

2. Empty email validation: If inviter.Email is empty (line 232), the notification will fail.

Apply this diff to harmonize fallbacks:

 	if inviterName == "" {
 		inviterName = inviter.Email
 	}
+	if inviterName == "" {
+		inviterName = "A user"
+	}
 
 	if domainName == "" {

And add email validation before sending:

+	if inviter.Email == "" {
+		logger.Warn("inviter has no email address",
+			slog.String("user_id", invitedBy),
+		)
+		return nil
+	}
+
 	// Send invitation accepted notification
 	notificationData := users.NotificationData{

cmd/users/main.go (3)

44-45: Remove duplicate import.

The package github.com/absmach/supermq/users/events is imported twice with different aliases (events on line 44 and userevents on line 45). Consolidate to a single import.

Apply this diff:

 	httpapi "github.com/absmach/supermq/users/api"
 	"github.com/absmach/supermq/users/emailer"
-	"github.com/absmach/supermq/users/events"
 	userevents "github.com/absmach/supermq/users/events"

Then update line 333 to use the alias consistently:

-	svc, err := events.NewEventStoreMiddleware(ctx, svc, c.ESURL)
+	svc, err := userevents.NewEventStoreMiddleware(ctx, svc, c.ESURL)

---

274-279: Add deferred close for subscriber.

The subscriber returned by store.NewSubscriber implements the events.Subscriber interface (pkg/events/events.go:51-56), which includes a Close() error method. Other clients in this file (tokenHandler, authnHandler, domainsHandler, authzHandler) all have deferred close calls. The subscriber needs the same cleanup pattern.

Apply this diff:

 	subscriber, err := store.NewSubscriber(ctx, cfg.ESURL, logger)
 	if err != nil {
 		logger.Error(fmt.Sprintf("failed to create event subscriber: %s", err))
 		exitCode = 1
 		return
 	}
+	defer subscriber.Close()

---

284-288: Log message printed before subscription is established.

The log "Subscribed to invitation events" (line 288) is printed immediately after spawning the goroutine, not after the subscription is confirmed. Since userevents.Start is asynchronous and may fail, consider logging inside the Start function after successful subscription or handling errors from the goroutine.

Consider moving the log into the Start function after sub.Subscribe succeeds (around line 51 in users/events/consumer.go):

if err := sub.Subscribe(ctx, subCfg); err != nil {
	return err
}
logger.Info("Subscribed to invitation events")
// Then enter blocking loop if applicable

users/emailer/notifier.go (1)

38-54: Consider defensive validation of metadata keys.

The metadata extraction doesn't validate that required keys exist. If a key is missing, an empty string is passed to the emailer, which could result in poorly formatted emails. While the event consumer in users/events/consumer.go provides fallbacks, adding defensive checks here would make the notifier more robust against future callers.

Example validation for notifyInvitationSent:

 func (n *emailNotifier) notifyInvitationSent(data users.NotificationData) error {
 	inviteeName := data.Metadata["invitee_name"]
 	inviterName := data.Metadata["inviter_name"]
 	domainName := data.Metadata["domain_name"]
 	roleName := data.Metadata["role_name"]
+
+	// Validate required metadata
+	if inviteeName == "" || inviterName == "" {
+		return fmt.Errorf("missing required metadata: invitee_name or inviter_name")
+	}
 
 	return n.emailer.SendInvitation(data.Recipients, inviteeName, inviterName, domainName, roleName)
 }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cmd/users/main.go (3)

28-28: Duplicate import already flagged.

The duplicate import of github.com/absmach/supermq/users/events on lines 44-45 has been identified in a previous review. Please refer to the existing comment for the suggested fix.

Also applies to: 44-45

---

277-282: Missing deferred close already flagged.

The missing defer subscriber.Close() call has been identified in a previous review. Please refer to the existing comment for the suggested fix.

---

284-288: Premature log message already flagged.

The timing issue with the log message "Subscribed to invitation events" has been identified in a previous review. Please refer to the existing comment for the suggested fix.

users/emailer/notifier.go (1)

27-40: Consider propagating context to underlying emailer calls.

The ctx parameter is accepted but not used. If the Emailer interface methods support context (or will in the future), consider propagating it for proper cancellation and timeout handling.

users/notifier.go (1)

22-32: Consider documenting required metadata keys per notification type.

The Metadata map is flexible but lacks documentation about which keys are required for each NotificationType. Consider adding documentation or constants for the expected keys:

// Metadata keys for NotificationPasswordReset
const (
    MetadataKeyUser  = "user"
    MetadataKeyToken = "token"
)
// ... similar for other types

This would help callers construct valid NotificationData without inspecting the notifier implementation.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro