carverauto/serviceradar

Fork 0

srql builder integration / sweep config updates #2654

Merged

mfreeman451 merged 9 commits from refs/pull/2654/head into staging

2026-01-12 07:30:35 +00:00

mfreeman451 commented

2026-01-12 05:48:19 +00:00

(Migrated from github.com)

Owner

Imported from GitHub pull request.

Original GitHub pull request: #2268
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2268
Original created: 2026-01-12T05:48:19Z
Original updated: 2026-01-12T07:30:36Z
Original head: carverauto/serviceradar:update/srql-builder-network-sweep
Original base: staging
Original merged: 2026-01-12T07:30:35Z by @mfreeman451

User description

IMPORTANT: Please sign the Developer Certificate of Origin

Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:

Signed-off-by: J. Doe <j.doe@domain.com>

Describe your changes

Issue ticket number and link

Code checklist before requesting a review

I have signed the DCO?
The build completes without errors?
All tests are passing when running make test?

PR Type

Enhancement

Description

Refocus SRQL builder integration on leveraging existing capabilities for network sweep targeting
Replace OR group grammar expansion with SRQL-based target extraction in SweepCompiler
Add periodic config refresh worker to handle device inventory changes
Ensure full device field/operator coverage in targeting rules UI

Diagram Walkthrough

flowchart LR
  A["User configures<br/>targeting rules"] -->|stores target_criteria| B["SweepCompiler"]
  B -->|executes SRQL query| C["Device inventory"]
  C -->|returns matching IPs| D["Compiled config"]
  D -->|sent to agent| E["Agent executes sweep"]
  F["SweepConfigRefreshWorker"] -->|periodic check| C
  F -->|hash changed| G["Invalidate cache"]
  G -->|publish event| D

File Walkthrough

Relevant files

Documentation

design.md `Redesign from OR grammar to SRQL-based targeting` openspec/changes/update-srql-builder-grammar/design.md Completely rewrote context from OR grouping support to SRQL-based target extraction approach Added comprehensive end-to-end flow diagram showing UI → SRQL → agent execution → results processing Shifted goals from OR grammar expansion to leveraging existing SRQL builder capabilities Added new section on config invalidation mechanism with periodic refresh worker pattern Updated decisions to focus on reusing existing builder and SRQL for target extraction Revised migration plan to focus on SweepCompiler refactoring and operator coverage verification	+99/-18
proposal.md `Refocus proposal on builder integration over grammar changes` openspec/changes/update-srql-builder-grammar/proposal.md Changed title from grammar expansion to SRQL builder integration for sweep targeting Shifted rationale from adding OR support to leveraging existing builder capabilities Removed SRQL grammar changes from scope; now documentation-only for SRQL spec Focused impact on web-ng UI and criteria-to-SRQL conversion instead of parser/planner changes Simplified scope to UI integration and operator coverage verification	+8/-8
spec.md `Replace OR grammar requirements with SRQL extraction and refresh` openspec/changes/update-srql-builder-grammar/specs/srql/spec.md Removed requirement for SRQL grouped boolean expressions with OR keyword and parentheses Replaced with requirement for SweepCompiler to use SRQL for target extraction Added scenarios for criteria-to-SRQL conversion with multiple criteria combined via AND Added requirement for periodic config refresh worker to detect device inventory changes Added scenarios for preview count accuracy and device attribute change detection Removed nested group parsing and match-any/all group generation requirements	+40/-19
tasks.md `Shift tasks from parser work to compiler and refresh worker` openspec/changes/update-srql-builder-grammar/tasks.md Removed tasks for SRQL parser/planner changes (OR groups, AST updates, grammar extensions) Added task 1 to refactor SweepCompiler for SRQL-based target extraction Added task 2 for implementing SweepConfigRefreshWorker with periodic execution and hash comparison Simplified task 3 to verify UI coverage of device fields and operators Simplified task 4 to verify SRQL conversion consistency Added task 5 for documentation updates on flow and refresh mechanism	+21/-14

Imported from GitHub pull request. Original GitHub pull request: #2268 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/2268 Original created: 2026-01-12T05:48:19Z Original updated: 2026-01-12T07:30:36Z Original head: carverauto/serviceradar:update/srql-builder-network-sweep Original base: staging Original merged: 2026-01-12T07:30:35Z by @mfreeman451 --- ### **User description** ## IMPORTANT: Please sign the Developer Certificate of Origin Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include a [DCO sign-off statement]( https://developercertificate.org/) indicating the DCO acceptance in one commit message. Here is an example DCO Signed-off-by line in a commit message: ``` Signed-off-by: J. Doe <j.doe@domain.com> ``` ## Describe your changes ## Issue ticket number and link ## Code checklist before requesting a review - [ ] I have signed the DCO? - [ ] The build completes without errors? - [ ] All tests are passing when running make test? ___ ### **PR Type** Enhancement ___ ### **Description** - Refocus SRQL builder integration on leveraging existing capabilities for network sweep targeting - Replace OR group grammar expansion with SRQL-based target extraction in SweepCompiler - Add periodic config refresh worker to handle device inventory changes - Ensure full device field/operator coverage in targeting rules UI ___ ### Diagram Walkthrough ```mermaid flowchart LR A["User configures<br/>targeting rules"] -->|stores target_criteria| B["SweepCompiler"] B -->|executes SRQL query| C["Device inventory"] C -->|returns matching IPs| D["Compiled config"] D -->|sent to agent| E["Agent executes sweep"] F["SweepConfigRefreshWorker"] -->|periodic check| C F -->|hash changed| G["Invalidate cache"] G -->|publish event| D ``` <details><summary><h3>File Walkthrough</h3></summary> <table><thead><tr><th></th><th align="left">Relevant files</th></tr></thead><tbody><tr><td><strong>Documentation</strong></td><td><table> <tr> <td> <details> <summary><strong>design.md</strong><dd><code>Redesign from OR grammar to SRQL-based targeting</code>                  </dd></summary> <hr> openspec/changes/update-srql-builder-grammar/design.md <ul><li>Completely rewrote context from OR grouping support to SRQL-based <br>target extraction approach<br> <li> Added comprehensive end-to-end flow diagram showing UI → SRQL → agent <br>execution → results processing<br> <li> Shifted goals from OR grammar expansion to leveraging existing SRQL <br>builder capabilities<br> <li> Added new section on config invalidation mechanism with periodic <br>refresh worker pattern<br> <li> Updated decisions to focus on reusing existing builder and SRQL for <br>target extraction<br> <li> Revised migration plan to focus on SweepCompiler refactoring and <br>operator coverage verification</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/2268/files#diff-1f94911f8fd75341f7fb128c3ea4246e47e72ca4ca9de602b0b379de1fe8f06b">+99/-18</a>  </td> </tr> <tr> <td> <details> <summary><strong>proposal.md</strong><dd><code>Refocus proposal on builder integration over grammar changes</code></dd></summary> <hr> openspec/changes/update-srql-builder-grammar/proposal.md <ul><li>Changed title from grammar expansion to SRQL builder integration for <br>sweep targeting<br> <li> Shifted rationale from adding OR support to leveraging existing <br>builder capabilities<br> <li> Removed SRQL grammar changes from scope; now documentation-only for <br>SRQL spec<br> <li> Focused impact on web-ng UI and criteria-to-SRQL conversion instead of <br>parser/planner changes<br> <li> Simplified scope to UI integration and operator coverage verification</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/2268/files#diff-4fd88ce5573471865061bc79d13426f318d72da0a05172e13353a8a033817daf">+8/-8</a>      </td> </tr> <tr> <td> <details> <summary><strong>spec.md</strong><dd><code>Replace OR grammar requirements with SRQL extraction and refresh</code></dd></summary> <hr> openspec/changes/update-srql-builder-grammar/specs/srql/spec.md <ul><li>Removed requirement for SRQL grouped boolean expressions with OR <br>keyword and parentheses<br> <li> Replaced with requirement for SweepCompiler to use SRQL for target <br>extraction<br> <li> Added scenarios for criteria-to-SRQL conversion with multiple criteria <br>combined via AND<br> <li> Added requirement for periodic config refresh worker to detect device <br>inventory changes<br> <li> Added scenarios for preview count accuracy and device attribute change <br>detection<br> <li> Removed nested group parsing and match-any/all group generation <br>requirements</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/2268/files#diff-50657f60f23abb24b4ef4409cfeea3e9ad6508c6b9bb87fade86163a210a6c0b">+40/-19</a>  </td> </tr> <tr> <td> <details> <summary><strong>tasks.md</strong><dd><code>Shift tasks from parser work to compiler and refresh worker</code></dd></summary> <hr> openspec/changes/update-srql-builder-grammar/tasks.md <ul><li>Removed tasks for SRQL parser/planner changes (OR groups, AST updates, <br>grammar extensions)<br> <li> Added task 1 to refactor SweepCompiler for SRQL-based target <br>extraction<br> <li> Added task 2 for implementing SweepConfigRefreshWorker with periodic <br>execution and hash comparison<br> <li> Simplified task 3 to verify UI coverage of device fields and operators<br> <li> Simplified task 4 to verify SRQL conversion consistency<br> <li> Added task 5 for documentation updates on flow and refresh mechanism</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/2268/files#diff-96c3fe01773b9b778c68856616562cf7e7142efd7617a4bc00df1ba947d5ef72">+21/-14</a>  </td> </tr> </table></td></tr></tbody></table> </details> ___

qodo-code-review[bot] commented

2026-01-12 05:48:57 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2268#issuecomment-3736979345
Original created: 2026-01-12T05:48:57Z

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪
	Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/2268#issuecomment-3736979345 Original created: 2026-01-12T05:48:57Z --- ## PR Compliance Guide 🔍  Below is a summary of compliance checks for this PR:<br> <table><tbody><tr><td colspan='2'><strong>Security Compliance</strong></td></tr> <tr><td>🟢</td><td><details><summary><strong>No security concerns identified</strong></summary> No security vulnerabilities detected by AI analysis. Human verification advised for critical code. </details></td></tr> <tr><td colspan='2'><strong>Ticket Compliance</strong></td></tr> <tr><td>⚪</td><td><details><summary>🎫 <strong>No ticket provided </strong></summary> - [ ] Create ticket/issue  </details></td></tr> <tr><td colspan='2'><strong>Codebase Duplication Compliance</strong></td></tr> <tr><td>⚪</td><td><details><summary><strong>Codebase context is not defined </strong></summary> Follow the <a href='https://qodo-merge-docs.qodo.ai/core-abilities/rag_context_enrichment/'>guide</a> to enable codebase context checks. </details></td></tr> <tr><td colspan='2'><strong>Custom Compliance</strong></td></tr> <tr><td rowspan=1>🟢</td><td> <details><summary><strong>Generic: Meaningful Naming and Self-Documenting Code</strong></summary><br> **Objective:** Ensure all identifiers clearly express their purpose and intent, making code <br>self-documenting<br> **Status:** Passed<br> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td rowspan=5>⚪</td> <tr><td align="center" colspan="2"> - [ ] Update  </td></tr></tbody></table> <details><summary>Compliance status legend</summary> 🟢 - Fully Compliant<br> 🟡 - Partial Compliant<br> 🔴 - Not Compliant<br> ⚪ - Requires Further Human Verification<br> 🏷️ - Compliance label<br> </details>

qodo-code-review[bot] commented

2026-01-12 05:49:59 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2268#issuecomment-3736981301
Original created: 2026-01-12T05:49:59Z

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ ~~Sort targets before hashing for determinism~~ Suggestion Impact: The documentation was updated to specify that the SweepConfigRefreshWorker computes a SHA256 hash of a sorted IP list (Enum.sort) before hashing, explicitly addressing determinism concerns in target hashing. code diff: +Solution (Implemented): `SweepConfigRefreshWorker` Oban job: +1. Runs every 5 minutes via cron (`/5 * * ` in `config_refresh` queue) 2. For each tenant's enabled sweep groups: - - Execute the SRQL query to get current target list - - Compute hash of the result set - - Compare with stored hash on the SweepGroup or ConfigInstance - - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval + - Execute Ash query to get current target IPs + - Compute SHA256 hash of sorted IP list + - Compare with stored `target_hash` on SweepGroup + - If changed, update hash and publish config invalidation via NATS +3. Agents receive updated configs within the refresh interval + +Implementation details:* +- `SweepGroup` has `target_hash` (text) and `target_hash_updated_at` (utc_datetime) attributes +- Hash computed via `:crypto.hash(:sha256, Enum.sort(ips) \|> Enum.join(","))` To ensure deterministic hashing, sort the list of target IPs from the SRQL query before computing the hash. This prevents unnecessary cache invalidations caused by inconsistent result ordering. openspec/changes/update-srql-builder-grammar/design.md [88-92] `2. For each tenant's enabled sweep groups: - Execute the SRQL query to get current target list - - Compute hash of the result set + - Sort the target list to ensure a canonical order + - Compute hash of the sorted result set - Compare with stored hash on the SweepGroup or ConfigInstance - If changed, invalidate the config cache and publish NATS event` `[Suggestion processed]` Suggestion importance[1-10]: 9 __ Why: This suggestion correctly identifies a critical flaw in the hashing logic that would lead to non-deterministic behavior and spurious cache invalidations. Sorting before hashing is essential for the correctness of the `SweepConfigRefreshWorker`.	High
General	✅ ~~Distribute worker load to prevent spikes~~ Suggestion Impact: The commit removed the proposed periodic SweepConfigRefreshWorker entirely and changed the design so targets are recomputed on each agent config poll, eliminating the periodic "process all sweep groups" refresh workload (and thus the potential spike) rather than implementing batching/sharding. code diff: -## Config Invalidation on Device Changes +## Target List Updates -The SRQL result set can change even when SweepGroup config stays the same: +The target result set can change even when SweepGroup config stays the same: - New devices discovered that match criteria -- Device attributes change (discovery_sources, partition, tags) +- Device attributes change (discovery_sources, tags) - Devices deleted -Current state: Only SweepGroup/SweepProfile changes trigger cache invalidation. - -Solution: Add a periodic Oban job `SweepConfigRefreshWorker` that: -1. Runs every N minutes (configurable, default 5 minutes) -2. For each tenant's enabled sweep groups: - - Execute the SRQL query to get current target list - - Compute hash of the result set - - Compare with stored hash on the SweepGroup or ConfigInstance - - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval - -Alternative considered: Adding a notifier to Device resource. Rejected because: -- High volume of device changes could cause excessive invalidations -- Bulk device imports would hammer the system -- Periodic refresh is more predictable and batches changes +How agents get updated targets: The SweepCompiler computes targets fresh from current device inventory on each config poll. No additional refresh mechanism or cache invalidation is needed - agents receive the current target list on every poll. To prevent system load spikes, distribute the `SweepConfigRefreshWorker`'s workload over time using batching or sharding instead of processing all sweep groups at once. openspec/changes/update-srql-builder-grammar/design.md [86-93] Solution: Add a periodic Oban job `SweepConfigRefreshWorker` that: -1. Runs every N minutes (configurable, default 5 minutes) -2. For each tenant's enabled sweep groups: +1. Runs every N minutes (configurable, default 5 minutes). The job should be designed to distribute the load over the interval to avoid query spikes. +2. For each tenant's enabled sweep groups (processed in batches or sharded across workers): - Execute the SRQL query to get current target list - Compute hash of the result set - Compare with stored hash on the SweepGroup or ConfigInstance - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval +3. This ensures agents receive updated configs within the refresh interval. `[Suggestion processed]` Suggestion importance[1-10]: 7 __ Why: The suggestion raises a valid scalability concern about the "thundering herd" problem and proposes sensible mitigation strategies. This is a valuable performance and reliability improvement for the proposed background job.	Medium
Update

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/2268#issuecomment-3736981301 Original created: 2026-01-12T05:49:59Z --- ## PR Code Suggestions ✨  Explore these optional code suggestions: <table><thead><tr><td><strong>Category</strong></td><td align=left><strong>Suggestion                                                                                                                                    </strong></td><td align=center><strong>Impact</strong></td></tr><tbody><tr><td rowspan=1>Possible issue</td> <td> <details><summary>✅ <s>Sort targets before hashing for determinism</s></summary> ___ <details><summary><b>Suggestion Impact:</b></summary>The documentation was updated to specify that the SweepConfigRefreshWorker computes a SHA256 hash of a sorted IP list (Enum.sort) before hashing, explicitly addressing determinism concerns in target hashing. code diff: ```diff +**Solution (Implemented):** `SweepConfigRefreshWorker` Oban job: +1. Runs every 5 minutes via cron (`*/5 * * * *` in `config_refresh` queue) 2. For each tenant's enabled sweep groups: - - Execute the SRQL query to get current target list - - Compute hash of the result set - - Compare with stored hash on the SweepGroup or ConfigInstance - - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval + - Execute Ash query to get current target IPs + - Compute SHA256 hash of sorted IP list + - Compare with stored `target_hash` on SweepGroup + - If changed, update hash and publish config invalidation via NATS +3. Agents receive updated configs within the refresh interval + +**Implementation details:** +- `SweepGroup` has `target_hash` (text) and `target_hash_updated_at` (utc_datetime) attributes +- Hash computed via `:crypto.hash(:sha256, Enum.sort(ips) |> Enum.join(","))` ``` </details> ___ **To ensure deterministic hashing, sort the list of target IPs from the SRQL query <br>before computing the hash. This prevents unnecessary cache invalidations caused <br>by inconsistent result ordering.** [openspec/changes/update-srql-builder-grammar/design.md [88-92]](https://github.com/carverauto/serviceradar/pull/2268/files#diff-1f94911f8fd75341f7fb128c3ea4246e47e72ca4ca9de602b0b379de1fe8f06bR88-R92) ```diff 2. For each tenant's enabled sweep groups: - Execute the SRQL query to get current target list - - Compute hash of the result set + - Sort the target list to ensure a canonical order + - Compute hash of the sorted result set - Compare with stored hash on the SweepGroup or ConfigInstance - If changed, invalidate the config cache and publish NATS event ``` `[Suggestion processed]` <details><summary>Suggestion importance[1-10]: 9</summary> __ Why: This suggestion correctly identifies a critical flaw in the hashing logic that would lead to non-deterministic behavior and spurious cache invalidations. Sorting before hashing is essential for the correctness of the `SweepConfigRefreshWorker`. </details></details></td><td align=center>High </td></tr><tr><td rowspan=1>General</td> <td> <details><summary>✅ <s>Distribute worker load to prevent spikes</s></summary> ___ <details><summary><b>Suggestion Impact:</b></summary>The commit removed the proposed periodic SweepConfigRefreshWorker entirely and changed the design so targets are recomputed on each agent config poll, eliminating the periodic "process all sweep groups" refresh workload (and thus the potential spike) rather than implementing batching/sharding. code diff: ```diff -## Config Invalidation on Device Changes +## Target List Updates -The SRQL result set can change even when SweepGroup config stays the same: +The target result set can change even when SweepGroup config stays the same: - New devices discovered that match criteria -- Device attributes change (discovery_sources, partition, tags) +- Device attributes change (discovery_sources, tags) - Devices deleted -**Current state:** Only SweepGroup/SweepProfile changes trigger cache invalidation. - -**Solution:** Add a periodic Oban job `SweepConfigRefreshWorker` that: -1. Runs every N minutes (configurable, default 5 minutes) -2. For each tenant's enabled sweep groups: - - Execute the SRQL query to get current target list - - Compute hash of the result set - - Compare with stored hash on the SweepGroup or ConfigInstance - - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval - -**Alternative considered:** Adding a notifier to Device resource. Rejected because: -- High volume of device changes could cause excessive invalidations -- Bulk device imports would hammer the system -- Periodic refresh is more predictable and batches changes +**How agents get updated targets:** The SweepCompiler computes targets fresh from current device inventory on each config poll. No additional refresh mechanism or cache invalidation is needed - agents receive the current target list on every poll. ``` </details> ___ **To prevent system load spikes, distribute the <code>SweepConfigRefreshWorker</code>'s <br>workload over time using batching or sharding instead of processing all sweep <br>groups at once.** [openspec/changes/update-srql-builder-grammar/design.md [86-93]](https://github.com/carverauto/serviceradar/pull/2268/files#diff-1f94911f8fd75341f7fb128c3ea4246e47e72ca4ca9de602b0b379de1fe8f06bR86-R93) ```diff **Solution:** Add a periodic Oban job `SweepConfigRefreshWorker` that: -1. Runs every N minutes (configurable, default 5 minutes) -2. For each tenant's enabled sweep groups: +1. Runs every N minutes (configurable, default 5 minutes). The job should be designed to distribute the load over the interval to avoid query spikes. +2. For each tenant's enabled sweep groups (processed in batches or sharded across workers): - Execute the SRQL query to get current target list - Compute hash of the result set - Compare with stored hash on the SweepGroup or ConfigInstance - If changed, invalidate the config cache and publish NATS event -3. This ensures agents receive updated configs within the refresh interval +3. This ensures agents receive updated configs within the refresh interval. ``` `[Suggestion processed]` <details><summary>Suggestion importance[1-10]: 7</summary> __ Why: The suggestion raises a valid scalability concern about the "thundering herd" problem and proposes sensible mitigation strategies. This is a valuable performance and reliability improvement for the proposed background job. </details></details></td><td align=center>Medium </td></tr> <tr><td align="center" colspan="2"> - [ ] Update  </td><td></td></tr></tbody></table>

mfreeman451 commented

2026-01-12 07:13:37 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR review comment.

Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2268#discussion_r2681094039
Original created: 2026-01-12T07:13:37Z
Original path: elixir/serviceradar_core/lib/serviceradar/infrastructure/state_monitor.ex
Original line: 351

no bueno

Imported GitHub PR review comment. Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/2268#discussion_r2681094039 Original created: 2026-01-12T07:13:37Z Original path: elixir/serviceradar_core/lib/serviceradar/infrastructure/state_monitor.ex Original line: 351 --- no bueno