[Logs Explorer] Notify the user about new log entries

[weltenwort]

📓 Summary

Since an auto-refresh is pretty heavy-handed and can disrupt the user experience, we should consider other options of notifying the user about new log entries. This is especially important when the user has just started on-boarding new log entries but configuration rollout and ingest is delayed. Therefore, when the user views log entries in a relative time range that ends now, we should notify them about the availability of new log entries without disrupting their current view.

• 🔗 related to: [Logs+] Enable refresh interval after onboarding wizard #163718

✔️ Acceptance criteria

• When the user starts viewing log entries for a relative time range ending now, the log explorer regularly checks in the background whether there are newer log entries than the newest one previously fetched. This takes into account the applied filters.
• When newer log entries are found, the user is notified about that. This could be via a toast message or some other UI indicator.
• The notification has a call to action, that refreshes the data.
• The notification only happens once until the user manually changes the filters or refreshes, so the user is not flooded with notifications.

💡 Implementation hints

stateDiagram-v2
  state is_now <<choice>>
  state has_new <<choice>>
  state "idle" as idle
  state "waiting" as waiting
  state "checking for newer" as checking
  state "notifying" as notifying
  
  [*] --> is_now
  is_now --> waiting: relative time range ends with `now`
  is_now --> idle: else
  waiting --> checking: after delay
  checking --> has_new
  has_new --> notifying: has newer entries
  has_new --> waiting: else
  notifying --> is_now: refetched
  idle --> is_now: refetched

Loading

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[ruflin]

I quite like this idea and sounds familiar from how other tools deal with updates without interrupting you reading a specific message.

Going into tech details: How do you expect the query to look like against Elasticsearch to keep the overhead to a minimum? Would we show users how many new messages are there and keep updating it from time to time?

[weltenwort]

I would start with a query that applies the same filters as the "main" query, but use size: 0, terminate_after: 1 and search_after with the newest timestamp seen in the previous query. And once we have found new data (i.e. are in the "notifying" state in my state machine from the description) we can stop checking until the user has caused a refetch.

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[isaclfreire]

I started to do some explorations about this issue in this Figma file. To some level, I think this discussion relates to the dataset activity (#171394)