Fix for Issue#518

[daminichopra]

Proposed changes

Inserted a start check to verify that crate back off factor

Types of changes

What types of changes does your code introduce to the project: Put
an x in the boxes that apply

• [ x ] Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing
  functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to
ask. We're here to help! This is simply a reminder of what we are going
to look for before merging your code.

• [ x ] I have read the CONTRIBUTING doc
• [ x ] I have signed the CLA
• I have added tests that prove my fix is effective or that my
  feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in
  downstream modules

Further comments

Fix for Issue

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️

[daminichopra]

@chicco785 Gentle Reminder for merging!!

[c0c0n3]

hi @daminichopra, thanks for this. I've just looked at the crate docs

• https://crate.io/docs/python/en/latest/connect.html#backoff-factor

where they explicitly mention the backoff factor should be between 0 and 120. So we need to output a config error not a warning. I suggest we change this PR as follows:

1. Implement a new config reader for float ranges, e.g. class FloatRangeVar(Evar) ...
   • FloatRangeVar gets instantiated with an interval [a b] where config values are expected to be, e.g. [0, 120] in your case.
   • on reading a config value x, FloatRangeVar raises a ValueError if x is not in [a, b].
2. Simply use this new config reader in the translator, e.g. backoff_factor = ... .read(FloatRangeVar('CRATE_BACKOFF_FACTOR', 0.0, 0, 120))

This way we get to reuse the validation code in the future if we have similar env vars. What do you think? Does it make any sense?

[c0c0n3]

@daminichopra thanks for your commits, if you could improve the code just slightly so we can reuse it for other range variables going forward---i.e. not just for the range [0, 120]. I sketched out in the review comments how we could do that. Also, we need to add unit tests for the new class FloatRangeVar similar to what we have already in utils/tests/test_cfgreader. Thank you soooo much!!

[c0c0n3]

Can we make this class more generic so it works for any range, not just the 0-120 range?
e.g.

class FloatRangeVar(EVar):
   def __init__(var_name, default_value, mask_value, lo, hi):
    # super(var_name, default_value, mask_value)
    # ...check lo <= hi

   def _do_read(self, rep: str) -> float:
     value = float(rep)
     if value not in range(self.lo, self.hi):
       raise ValueError(...)
     return value

[c0c0n3]

If we make FloatRangeVar generic (see comment below) then I think this line should be

.read(FloatRangeVar(var_name='CRATE_BACKOFF_FACTOR', default_value=0.0, lo=0.0, hi=120.0)