-
Notifications
You must be signed in to change notification settings - Fork 90
Description
The ActiveScheduleEvent on the Thermostat cluster has fields defined like so:
|===
| ID | Name | Type | Constraint | Quality | Fallback | Conformance
| 0 s| PreviousScheduleHandle | octstr | max 16 | X | | O
| 1 s| CurrentScheduleHandle | octstr | max 16 | X | | M
|===
The PreviousScheduleHandle field is defined as nullable and optional; this is because the attribute that it's recording can be null, and it's also possible that an implementation does not know the previous value. So, if the implementation knows the previous value, and it's null, it can indicate the field and set its value to null. If it does not know the previous value, it omits the field.
The generated Java code for this field looks like this:
values.add(new StructElement(PREVIOUS_SCHEDULE_HANDLE_ID, previousScheduleHandle != null ? previousScheduleHandle.<BaseTLVType>map((nonOptionalpreviousScheduleHandle) -> new ByteArrayType(nonOptionalpreviousScheduleHandle)).orElse(new EmptyType()) : new NullType()));
Gemini does not like this, commenting:
...this logic doesn't correctly differentiate between a missing previousScheduleHandle and an explicitly null previousScheduleHandle. This can lead to data loss or misinterpretation. The code should be updated to handle explicit null values correctly.
I think that it might be incorrect, depending on how the orElse function works, but perhaps there's a way to structure this code such that Gemini won't complain every time?