Skip to content

Numeric initial value no longer hardcoded to 0 - #415

Open
olliesilvester wants to merge 3 commits into
DiamondLightSource:mainfrom
olliesilvester:shared_write_pv_ignores_initial_value
Open

Numeric initial value no longer hardcoded to 0#415
olliesilvester wants to merge 3 commits into
DiamondLightSource:mainfrom
olliesilvester:shared_write_pv_ignores_initial_value

Conversation

@olliesilvester

@olliesilvester olliesilvester commented Aug 5, 2026

Copy link
Copy Markdown

New logic for initial value on numeric datatypes. Not obvious to me what the initial value should with a given set of upper and lower bounds, this seemed sensible-ish to me. Depending on the bounds specified, initial val is either set to the min, 0, or the max

Fixes #414

Summary by CodeRabbit

  • Bug Fixes

    • Numeric fields now start with a valid initial value when their configured range excludes zero.
    • Positive minimums and fully negative ranges are handled correctly.
  • Tests

    • Added coverage for constrained and unconstrained numeric ranges, including positive-only and negative-only values.

@coderabbitai

coderabbitai Bot commented Aug 5, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 20eea645-e608-4627-9ec6-fdf89ad0e299

📥 Commits

Reviewing files that changed from the base of the PR and between f0e3356 and edddc12.

📒 Files selected for processing (2)
  • src/fastcs/datatypes/_numeric.py
  • tests/test_datatypes.py

📝 Walkthrough

Walkthrough

Changes

Numeric initial value selection

Layer / File(s) Summary
Bound-aware initial values
src/fastcs/datatypes/_numeric.py, tests/test_datatypes.py
_Numeric.initial_value returns a valid positive minimum or negative bound when zero is outside the configured range. Parameterized tests cover Int and Float datatypes with bounded and unbounded configurations.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main change to numeric initial-value logic.
Linked Issues check ✅ Passed The changes address issue #414 by selecting a valid positive minimum instead of using 0 as the numeric initial value.
Out of Scope Changes check ✅ Passed The implementation and tests are limited to numeric initial-value selection required by issue #414.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
tests/transports/epics/pva/test_p4p.py (1)

229-232: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Make the AttrW test distinguish the fallback source.

AttrW(Int()) expects 0, so the test also passes if the implementation uses a hard-coded 0. Use a datatype fixture with a non-zero initial_value and assert that value.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/transports/epics/pva/test_p4p.py` around lines 229 - 232, Update
test_attr_w_shared_write_pv_uses_datatype_initial_value to construct AttrW with
a datatype fixture whose initial_value is non-zero, then assert
shared_pv.current()["value"] matches that value instead of hard-coded zero. Keep
the test focused on verifying the datatype-provided initial value.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@tests/transports/epics/pva/test_p4p.py`:
- Around line 229-232: Update
test_attr_w_shared_write_pv_uses_datatype_initial_value to construct AttrW with
a datatype fixture whose initial_value is non-zero, then assert
shared_pv.current()["value"] matches that value instead of hard-coded zero. Keep
the test focused on verifying the datatype-provided initial value.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: b1b6c2f7-3ed9-4a08-af70-5e5cd8bd99b8

📥 Commits

Reviewing files that changed from the base of the PR and between a2e77b6 and f0e3356.

📒 Files selected for processing (2)
  • src/fastcs/transports/epics/pva/_pv_handlers.py
  • tests/transports/epics/pva/test_p4p.py

@olliesilvester olliesilvester changed the title Shared write pv ignores initial value Shared write pv uses real initial value Aug 5, 2026
@olliesilvester
olliesilvester marked this pull request as draft August 5, 2026 07:52
@olliesilvester olliesilvester changed the title Shared write pv uses real initial value Numeric initial value no longer hardcoded to 0 Aug 6, 2026
@olliesilvester
olliesilvester marked this pull request as ready for review August 6, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PVA AttrRW setpoint PV errors with minimum > 0

1 participant