Last-activity Updates

Overview

The platform needs to know whether each user is still engaged — when they last did something, what kind of activity it was, and how long they have been quiet. That data feeds three places: segmentation (for conditions such as "inactive for more than 30 days"), the user list in the CMS, and the conditions of certain trigger rules.

This is a lightweight consumer whose only job is to update the last_activity_ fields on the line_user row. It is split into its own queue so that the database write never slows down the real-time paths that respond to the user.

Business Flow

1. Receive a LineUserActivityPayload containing lineUserId, lineOaId, organizationId, and the activity type and status.
2. ProcessLineUserLastActivity looks up the line_user row matching organizationId, lineOaId, and lineUserId.
3. Update four fields:
   • last_activity_type — the activity kind, such as message, follow, or click
   • last_activity_status — active or inactive
   • last_activity_period — the bucket derived from the gap between activities
   • last_activity_date — the current timestamp
4. A Redis cache of the line_user row lives at LINE_USER:<lineUserId> and is read by other flows in the system.
5. The service handles its own errors — it logs and returns — so the handler always returns nil and acks every message. This matches the legacy behaviour: a metadata update should never leave messages stuck in the queue.

Key Files & Functions

• internal/lineuser/service.go
  • Service.ProcessLineUserLastActivity(ctx, payload) — the main flow
  • findByLineUserId() — reads the Redis cache at LINE_USER:<id> first and falls back to the database. Note that it does not write the cache on a miss, matching the original source.
  • moduleName is LINE_USER, used as the Redis key prefix
• internal/lineuser/consumer.go — Consumer.HandleTrackingLog, bound to the line_user_last_activity queue
• internal/lineuser/types.go — defines LineUserActivityPayload
• Queue: line_user_last_activity (runtime profile main)

Connections to Other Services

• Job source — line-management-webhook-go, plus the tracking and redirect paths that need to record activity without blocking their response.
• Database — the line_user table, updating last_activity_type, last_activity_status, last_activity_period, and last_activity_date.
• Redis — the key LINE_USER:<lineUserId>.
• No LINE API calls.
• Downstream consumers of this data — audience filters in cms-api, attribute-based trigger rules, and the user reports in cms-web.