DiamondLightSource / DiamondLightSource/fastcs-odin
Make unpacked parameter with consistent type
- Dominant language
- Python
- Stars
- 1
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
On the **unpack_status_array** function the **type** field in the new OdinParameter is [defined by the original parameter metadata type](https://github.com/DiamondLightSource/fastcs-odin/blob/main/src/fastcs_odin/util.py#L227C1-L227C58). This can causes some issues, because when we try to unpack an OdinParameter that has a list as it's value the [metadata will always be assumed to be of string type](https://github.com/DiamondLightSource/fastcs-odin/blob/main/src/fastcs_odin/util.py#L127). This is not ideal for cases where we're handling a list of numerical types (int/floats), for example.
I suggest we change the function to build the new parameter with a similar logic to that of the **[infer_metadata](https://github.com/DiamondLightSource/fastcs-odin/blob/main/src/fastcs_odin/util.py#L136C5-L136C19)** function so that the expected value is coherent.
Contributor guide
Research direction
Start in src/fastcs_odin/util.py by reading unpack_status_array, the OdinParameter construction around line 227, and infer_metadata around line 136. Check how list-valued parameters are unpacked and ensure the resulting parameter metadata reflects the list's numerical element type rather than always using string metadata.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100