minimal implementation of care partner alerts #715
Commits on Oct 31, 2024
-
adds List and Get methods to alerts client
The Get endpoint already exists on the service, so only the List endpoint needed to be added there. BACK-2554
-
lift Repeat out of the base alert config
Through discussions it was confirmed that Repeat is not universal to all alerts. So it's lifted out of the Base alert and re-inserted into those alerts where it should be present (namely Low and High alerts only). BACK-2554
-
adds activity tracking to alert configurations
These activity properties will track the times at which alerts were sent, resolved, or acknowledged. BACK-2554
-
adds auth endpoint to retrieve a user's device tokens
This endpoint will be used by upcoming changes to the auth client to allow care partner backend processes to retrieve device tokens in order to send mobile device push notifications. BACK-2554
-
adds the ability to retrieve device tokens to the auth client
This functionality will be used by care partner processes to retrieve device tokens in order to send mobile device push notifications in response to care partner alerts being triggered. BACK-2554
-
remove unused device tokens repo from data
This was missed when moving device tokens from the data service to the auth service in commit a0f5a84. BACK-2554
-
adds a pusher client for sending APNs push notifications
Basic steps are taken to allow for other push notification services to be easily added in the future. BACK-2554
-
adapts sarama.Logger to implement log.Logger
So that sarama log messages better follow our standards, and will be emitted as JSON when log.Logger is configured for that. Before this change, the sarama logs were printed in plain-text without any of the benefits of the platform log.Logger. BACK-2554
-
adapts go-common's asyncevents.SaramaEventsConsumer for alerts
The existing FaultTolerantConsumer isn't used because it's retry semantics are hard-wired and aren't compatible with what care partner alerting's needs. Note: A proper implementation of AlertsEventsConsumer to consume events is yet to be written. It will follow shortly. BACK-2554
-
allow invites to set an upload id
The upload id is necessary to ensure that only the proper device data uploads are evaluated for care partner alert conditions. BACK-2554
-
integrates an APNs pusher into data service
If the necessary configuration isn't found, then push notifications will instead be logged. BACK-2554
-
adds Evaluate methods to alerts.Config
These methods return Note objects that can be sent as push notifications. NotLooping evaluation will be handled in a later commit. BACK-2554
-
adds the alerts events consumer to the data service
It uses the new asyncevents from go-common, as alerts processing requires different retry semantics than the existing solution. The Pusher interface is moved out of data/service into data/events to avoid a circular dependency. BACK-2554
-
-
In response to request during code review.
-
one mock of DeviceTokenRepository is enough
As caught by Todd in code review. BACK-2554
-
add a topic cascading retry mechanism for care partner alerts
When a care partner alert encounters an error, the message is moved to a separate topic that will cause it to be retried after a delay. Any number of these topics can be configured. BACK-2499
-
modifies DelayingConsumer to use a message header instead of a delay
Instead of a static delay, uses a "not before" time found in a Kafka message header. Consumption of the message will not be attempted until the time has passed. This allows for more accurate delays, as the time required to process an earlier message doesn't further delay the current message's processing. BACK-2449
-
-
don't read topic and consumer group id from runtime configuration
These won't be changing at runtime, so there's no need to complicate the initialization by making these configurable. The topic's prefix is configurable, and that's the part that will change from environment to environment at runtime. BACK-2554
