fix(launch_manager): enable ASSERT_DBG in unit tests

[hskang-amelia]

Summary

Follow-up to #542 (comment: #542 (comment)).

lm_cc_test (the shared cc_test wrapper used by launch_manager's unit tests, tests/utils/bazel/unit_test.bzl) never defined SCORE_LANGUAGE_FUTURECPP_ASSERT_LEVEL_DEBUG. Without it, SCORE_LANGUAGE_FUTURECPP_ASSERT_DBG/_DBG_MESSAGE checks compile down to a no-op dummy (see score/language/futurecpp's assert.hpp), so every debug-level assertion in launch_manager was silently unchecked in CI — build/link succeeds either way, so this was easy to miss.

Several existing call sites rely on this macro and were never actually being exercised:

• score/launch_manager/src/daemon/src/process_group_manager/details/graph.cpp
• score/launch_manager/src/daemon/src/process_group_manager/details/process_info_node.cpp
• score/launch_manager/src/daemon/src/process_group_manager/details/dependency_graph.hpp
• score/launch_manager/src/daemon/src/common/alive_interface_path.hpp
• score/launch_manager/src/lm_control/src/details/lm_control_impl.hpp

Wires the define into lm_cc_test itself so it applies uniformly to all launch_manager unit tests, rather than adding it target-by-target.

Test plan

• bazel test --lockfile_mode=error --config=x86_64-linux //score/launch_manager/... — all previously-passing tests still pass with the define enabled (verified specifically graph_UT and process_group_manager_UT, which exercise the affected call sites)
• buildifier --mode=check on the changed .bzl file
• CI

Fixes the follow-up raised in #542.

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.7.0) and connecting to it...
INFO: Invocation ID: 73b412ac-b50d-4a65-919f-994ae7ebd7dd
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

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

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

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

Analyzing: target //:license-check (147 packages loaded, 1296 targets configured)

Analyzing: target //:license-check (155 packages loaded, 6243 targets configured)

Analyzing: target //:license-check (160 packages loaded, 6259 targets configured)

Analyzing: target //:license-check (162 packages loaded, 6388 targets configured)

Analyzing: target //:license-check (167 packages loaded, 11377 targets configured)

Analyzing: target //:license-check (172 packages loaded, 11429 targets configured)

INFO: Analyzed target //:license-check (173 packages loaded, 11555 targets configured).
[9 / 16] Creating runfiles tree bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/score_tooling+/dash/tool/formatters/dash_format_converter.runfiles [for tool]; 0s local
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.143s, Critical Path: 0.23s
INFO: 16 processes: 4 disk cache hit, 12 internal.
INFO: Build completed successfully, 16 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>]

[danth]

Is it possible to also enable this for integration tests?

[hskang-amelia]

Is it possible to also enable this for integration tests?

Good question — yes, it's possible, but it needs a bit more than the one-line macro change this PR makes for unit tests. lm_cc_test only affects the cc_test binary it wraps, but the integration tests here link the actual production launch_manager daemon binary (//score/launch_manager) directly as the binary under test, so enabling the define there would mean enabling it on the same target that ships in production — so I prototyped this as a separate opt-in build variant instead:

• Split the daemon's cc_binary into a small macro (launch_manager_binary) so a second target, launch_manager_debug_asserts, can share the same srcs/deps but add SCORE_LANGUAGE_FUTURECPP_ASSERT_LEVEL_DEBUG, leaving the production launch_manager target untouched.
• Pointed the binaries list in each tests/integration/*/BUILD at the debug variant instead.
• Had to add a binary_renames option to integration_test() (backed by pkg_files's renames) so the packaged binary still shows up as launch_manager in the test environment — the test scripts hardcode that filename, and swapping the Bazel target name alone changes the default output filename too.

Verified locally in host mode: 19 of 21 integration tests pass unchanged with the debug-assert binary; the other 2 failures reproduce identically on main with no changes, so they're pre-existing local environment issues, not caused by this.

Happy to open this as a follow-up PR on top of this one if that's useful — didn't want to bundle it into #579 since it touches integration.bzl and 21 test BUILD files. Let me know if you'd rather I fold it in here instead.

[github-actions]

Documentation preview for this pull request is available at:
pr-579: https://eclipse-score.github.io/lifecycle/pr-579/

[MaciejKaszynski]

Is it possible to also enable this for integration tests?

Good question — yes, it's possible, but it needs a bit more than the one-line macro change this PR makes for unit tests. lm_cc_test only affects the cc_test binary it wraps, but the integration tests here link the actual production launch_manager daemon binary (//score/launch_manager) directly as the binary under test, so enabling the define there would mean enabling it on the same target that ships in production — so I prototyped this as a separate opt-in build variant instead:

* Split the daemon's cc_binary into a small macro (launch_manager_binary) so a second target, launch_manager_debug_asserts, can share the same srcs/deps but add SCORE_LANGUAGE_FUTURECPP_ASSERT_LEVEL_DEBUG, leaving the production launch_manager target untouched.

* Pointed the binaries list in each tests/integration/*/BUILD at the debug variant instead.

* Had to add a binary_renames option to integration_test() (backed by pkg_files's renames) so the packaged binary still shows up as launch_manager in the test environment — the test scripts hardcode that filename, and swapping the Bazel target name alone changes the default output filename too.

Verified locally in host mode: 19 of 21 integration tests pass unchanged with the debug-assert binary; the other 2 failures reproduce identically on main with no changes, so they're pre-existing local environment issues, not caused by this.

Happy to open this as a follow-up PR on top of this one if that's useful — didn't want to bundle it into #579 since it touches integration.bzl and 21 test BUILD files. Let me know if you'd rather I fold it in here instead.

Would be great if you can make a draft PR with the failing tests so the failures can be worked on.

[hskang-amelia]

Would be great if you can make a draft PR with the failing tests so the failures can be worked on.

Hi @MaciejKaszynski
Opened as a draft: #591 — includes the two known-failing tests. Turned out both are pre-existing local-environment issues (a Rust-toolchain/GLIBC mismatch pulled in by one test's health_monitor dependency, and a missing real-time-scheduling capability in this container for another), not caused by the debug-assert change; the PR description has details. Let's see how they look under CI's Docker-mode integration tests.