[TAM-2039] Add affected sensors to table, add cached alert schedule result for bar sensors

[GonzoSpire]

No description provided.

[github-actions]

Code Review: TAM-2039 — Add affected sensors to table, add cached alert schedule result for bar sensors

Bugs / Logic Errors

1. Duplicate sensors in GetSensorsByAlertSchedule (TreeValuesCache.cs)

The continue inside the inner foreach only advances to the next policy, not the next sensor. If a sensor has multiple policies that share the same ScheduleId, it will be added to result more than once.

foreach (var policy in sensor.Policies)
{
    if (policy.ScheduleId == id)
    {
        result.Add(sensor);
        continue;   // ← skips remaining policies but does NOT exit the outer loop
    }
}

Fix: use break instead of continue, or restructure with Any():

if (sensor.Policies.Any(p => p.ScheduleId == id))
    result.Add(sensor);

---

2. Missing timezone conversion in AlertSchedule.IsWorkingTime(startTime, endTime) (AlertSchedule.cs)

The existing single-point overload converts the input UTC time to the schedule's configured timezone via ConvertUtcToLocalTime before checking working windows. The new interval overload skips this conversion entirely and compares raw startTime/endTime values directly against local working windows. This will produce incorrect results for any non-UTC timezone.

// Single-point version (correct)
public bool IsWorkingTime(DateTime dateTime)
{
    var localTime = ConvertUtcToLocalTime(dateTime);
    // ... checks against localTime

// Interval version (missing conversion)
public bool IsWorkingTime(DateTime startTime, DateTime endTime)
{
    var currentTime = startTime;   // ← no ConvertUtcToLocalTime call
    ...
}

---

3. IntervalCache grows unbounded (AlertScheduleProvider.cs)

CacheEntry.IntervalCache is keyed on exact (DateTime startTime, DateTime endTime) pairs. Bar sensors will produce a new unique pair on every data point — the cache will accumulate indefinitely and is only cleared when a schedule is saved/deleted (InvalidateCache). For high-frequency bar sensors this becomes a slow memory leak, and the caching provides no benefit since the same (open, close) pair rarely repeats.

Consider either:

• Dropping the per-interval cache entirely (computing is cheap), or
• Bounding the cache size (e.g. LRU or a fixed max entry count).

---

Code Quality

4. ArgumentException missing parameter name

Both AlertSchedule.IsWorkingTime and AlertScheduleProvider.IsWorkingTime throw:

throw new ArgumentException("Start time must be less than end time");

The conventional overload includes the parameter name for easier debugging:

throw new ArgumentException("Start time must be less than end time", nameof(startTime));

---

5. Commented-out code block in tree.js

A large block of old logic was left commented out rather than removed. Dead code should be deleted — git history preserves the original if it's needed later.

//if (jQuery.isEmptyObject(prevState) && prevState !== undefined) {
//    let jstreeState = JSON.parse(localStorage.getItem('jstree'));
//    ...
//}

---

6. Formatting issues

• AlertSchedulesController.cs — closing brace for the class body is misaligned (the } for GetAlertScheduleList sits at the same level as the namespace closing brace).
• Extra blank lines in _ProductList.cshtml and AlertScheduleProvider.cs.
• Both modified files (ITreeValuesCache.cs, AlertSchedulesController.cs, TreeValuesCache.cs) are now missing a trailing newline.

---

Minor / Positive Notes

• Renaming Milleseconds → MillisecondsInSecond and returning 0 (not roundtrip time) on failed ping is correct.
• Making TimeZoneList a static Lazy<> is a good performance improvement.
• InvalidateCache() correctly also clears IntervalCache.
• Improved error logging on schedule parse failure (catch (Exception ex)) is a nice observability win.
• The ConvertUtcToLocalTime fix for DateTimeKind.Local input is correct.