Health Monitoring interaction view #52

pawelrutkaq · 2026-01-27T12:39:31Z

For now kept in HM component, shall be actually in some common place as it shows all 3 components working together.

github-actions · 2026-01-27T12:40:38Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 6d4c6e54-0af2-4f3d-ac28-b443e71207de
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'rust_qnx8_toolchain+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-eQOopREOYCL5vtTb6c1cwZrql4GVrJ1FqgxarQRe1xs="
DEBUG: Repository rust_qnx8_toolchain+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 2 packages loaded
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Loading: 2 packages loaded
    currently loading: 
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)
Analyzing: target //:license-check (3 packages loaded, 0 targets configured)

Analyzing: target //:license-check (37 packages loaded, 10 targets configured)

Analyzing: target //:license-check (89 packages loaded, 10 targets configured)

Analyzing: target //:license-check (131 packages loaded, 78 targets configured)

Analyzing: target //:license-check (148 packages loaded, 2913 targets configured)

Analyzing: target //:license-check (153 packages loaded, 4964 targets configured)

Analyzing: target //:license-check (153 packages loaded, 4964 targets configured)

Analyzing: target //:license-check (159 packages loaded, 9534 targets configured)

Analyzing: target //:license-check (161 packages loaded, 13571 targets configured)

Analyzing: target //:license-check (161 packages loaded, 13571 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 13697 targets configured).
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 27.334s, Critical Path: 0.37s
INFO: 13 processes: 4 disk cache hit, 9 internal.
INFO: Build completed successfully, 13 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

github-actions · 2026-01-27T12:41:48Z

The created documentation from the pull request is available at: docu-html

NicolasFussberger · 2026-01-27T14:56:42Z

docs/module/health_monitor/architecture/assets/hm_startup.puml

+HealthMonitorBuilder --> user: HealthMonitor instance
+
+user -> HealthMonitor: start()
+HealthMonitor -> LaunchDaemon: notify_started(timestamp)


One point of discussion could be if we want to explicitly start the monitoring via a separate IPC call notify_started(timestamp) as described here or just use the existing report_running as a trigger for launch_manager to start the monitoring.

From the user point of view it could be viewed as redundant to have both as both say somewhat "I finished initialization".

I am not sure which one is better, there seem to be advantages/disadvantages in both approaches.

A related question would be: Do we want to support monitoring of applications that do not use the lifecycle api and do not report running state? The diagram currently assumes no.

notify_started is nothing user calls, user calls HealthMonitor.start() - this call is needed anyway and I thought it will be better if we have at LaunchDaemon clear information that user have started it, otherwise its fully bogus setup that will finalize with LaunchDaemon thinking there is no alive ping. But, guess both optios are valid.

Yes, assumes no - but this does not cover system monitoring, so i still expect you may be monitoring on process level, but this was not the scope of this flow.

NicolasFussberger · 2026-01-27T15:01:39Z

docs/module/health_monitor/architecture/assets/hm_startup.puml

+
+== Application Side ==
+
+user -> HealthMonitorBuilder : build(supervisor_api_notification_cycle_time, ...)


I would like to add to this diagram:

During startup launch_manager reads its config for the application and will know whether it should be monitored or not.

If monitoring is enabled, the launch_manager will setup the required IPC communication when starting the process

NicolasFussberger · 2026-01-27T15:04:22Z

docs/module/health_monitor/architecture/assets/hm_startup.puml

+...
+
+user -> Lifecycle: report_running()
+Lifecycle -> LaunchDaemon


I think we should also depict when the monitoring stops during shutdown of the application.

My assumption would be that:

Launch_manager stops monitoring at the point in time it sends SIGTERM to the application process

Open question:
Does the sending of alive notification on the application side need to be stopped, or is it enough that these are just ignored by launch_manager?
Do we want to support monitoring for "self-terminating" applications that terminate on their own?

Since in app library does not take actions, it shall be fine just to do nothing there. But we shall describe it - correct.

"My assumption would be that" - you mean a point in which the app receive shutdown request via lifecycle ?

vinodreddy-g · 2026-01-29T12:30:59Z

docs/module/health_monitor/architecture/assets/hm_shutdown.puml

+    main -> HealthMonitor: destroy()
+    HealthMonitor -> LaunchDaemon: notify_stopped(timestamp)
+    note left
+    Notification is send to keep consistent with self terminating case


We have to show the case when the notify_stopped was send but the app did not shutdown within the timeout?

vinodreddy-g · 2026-01-29T12:32:28Z

docs/module/health_monitor/architecture/assets/hm_startup.puml

+end note
+...
+
+user -> Lifecycle: report_running()


We should show the case when the timeout of startup to running was crossed?

vinodreddy-g · 2026-01-29T12:36:43Z

docs/module/health_monitor/architecture/assets/hm_startup.puml

+HealthMonitorBuilder --> user: HealthMonitor instance
+
+user -> HealthMonitor: start()
+HealthMonitor -> LaunchDaemon: notify_started(timestamp)


Who is setting up the ipc channel and how?

This is not yet in scope as we did not tackled usage of mw::com as API. So this we will add once we design MW:COM api after having first working version.

pawelrutkaq temporarily deployed to workflow-approval January 27, 2026 12:39 — with GitHub Actions Inactive

Health Monitoring interaction view

3493f35

pawelrutkaq force-pushed the interaction_sequence_diagrams branch from 6f2302a to 3493f35 Compare January 27, 2026 12:46

pawelrutkaq temporarily deployed to workflow-approval January 27, 2026 12:46 — with GitHub Actions Inactive

NicolasFussberger reviewed Jan 27, 2026

View reviewed changes

Add extensions after review

e788684

pawelrutkaq temporarily deployed to workflow-approval January 28, 2026 11:42 — with GitHub Actions Inactive

vinodreddy-g reviewed Jan 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Health Monitoring interaction view #52

Health Monitoring interaction view #52

pawelrutkaq commented Jan 27, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 27, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 27, 2026

Uh oh!

NicolasFussberger Jan 27, 2026

Uh oh!

pawelrutkaq Jan 28, 2026

Uh oh!

NicolasFussberger Jan 27, 2026

Uh oh!

NicolasFussberger Jan 27, 2026 •

edited

Loading

Uh oh!

pawelrutkaq Jan 28, 2026

Uh oh!

vinodreddy-g Jan 29, 2026

Uh oh!

vinodreddy-g Jan 29, 2026 •

edited

Loading

Uh oh!

vinodreddy-g Jan 29, 2026 •

edited

Loading

Uh oh!

pawelrutkaq Jan 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		== Application Side ==

		user -> HealthMonitorBuilder : build(supervisor_api_notification_cycle_time, ...)

Health Monitoring interaction view #52

Are you sure you want to change the base?

Health Monitoring interaction view #52

Conversation

pawelrutkaq commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

github-actions bot commented Jan 27, 2026

Uh oh!

NicolasFussberger Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

NicolasFussberger Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

NicolasFussberger Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

vinodreddy-g Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

vinodreddy-g Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinodreddy-g Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pawelrutkaq Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pawelrutkaq commented Jan 27, 2026 •

edited

Loading

github-actions bot commented Jan 27, 2026 •

edited

Loading

NicolasFussberger Jan 27, 2026 •

edited

Loading

vinodreddy-g Jan 29, 2026 •

edited

Loading

vinodreddy-g Jan 29, 2026 •

edited

Loading