Fix end_time not handling None values correctly#164
Fix end_time not handling None values correctly#164Marenz merged 1 commit intofrequenz-floss:v0.x.xfrom
end_time not handling None values correctly#164Conversation
github-actions
bot
added
part:docs
There was a problem hiding this comment.
Pull Request Overview
This PR fixes the issue where a None value for end_time was not handled correctly during protobuf conversions. The changes ensure that end_time is properly converted to/from protobuf when its value is None.
- Added a test case to verify that Dispatch instances correctly handle end_time = None.
- Updated both from_protobuf and to_protobuf methods to conditionally process end_time.
- Updated RELEASE_NOTES to document the bug fix.
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/test_proto.py | Added a test case for Dispatch with a None end_time. |
| src/frequenz/client/dispatch/types.py | Updated protobuf conversions for end_time with a conditional check for None. |
| RELEASE_NOTES.md | Documented the bug fix for end_time handling. |
Marenz
force-pushed
the
fix_end_time_none_handling
branch
from
4d1c605 to
4410ade
Compare
Signed-off-by: Mathias L. Baumann <mathias.baumann@frequenz.com>
Marenz
force-pushed
the
fix_end_time_none_handling
branch
from
4410ade to
03610c5
Compare
llucax
left a comment
llucax
left a comment
There was a problem hiding this comment.
LGTM, but I think the release notes could be improved. It is more useful to describe the user-visible effect of the bug. As a user I have no idea about how this bug manifested.
| end_time=to_datetime(pb_object.metadata.end_time), | ||
| end_time=( | ||
| to_datetime(pb_object.metadata.end_time) | ||
| if pb_object.metadata.HasField("end_time") |
There was a problem hiding this comment.
I think we have this bug in many places in all API clients. We need to be more careful about optional/non-existing fields... For sure I've seen it in the microgrid API, but I think we are lucky there because most stuff we should check if they exist is always filled by the server, so we are not seeing the effect of the bug there.
2 participants
fixes #162