Skip to content

Gemini complains about generated Java code for events with optional fields #1621

@hasty

Description

@hasty

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions