Fix: If lower bound specified for availability, upper bound should be 1.0

[alexdewar]

Description

I stumbled across this while I was looking something up and it seemed fishy to me.

If you specify a lower bound for a process availability, the upper bound is set to infinity, whereas it should be 100% instead. It would be ok if we had other constraints which prevented activity from exceeding 100%, but we don't. In practice this hasn't proven to be a problem because all the examples only specify upper bounds. Also, the optimiser will generally try to minimise activity anyway, because less activity means lower cost, but we shouldn't rely on this.

Fix by setting the upper limit to 100%.

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.86%. Comparing base (9f77d38) to head (e6a9c63).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #955   +/-   ##
=======================================
  Coverage   83.86%   83.86%           
=======================================
  Files          50       50           
  Lines        5540     5541    +1     
  Branches     5540     5541    +1     
=======================================
+ Hits         4646     4647    +1     
  Misses        658      658           
  Partials      236      236           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alexdewar]

I am wondering whether a "proportion" type that can only have values >=0 and <=1 might be useful for catching problems like this.

[tsmbland]

Well spotted!

[tsmbland]

I am wondering whether a "proportion" type that can only have values >=0 and <=1 might be useful for catching problems like this.

Potentially, not sure how often this would crop up though, whether it's worth the effort...