xnumber leads to PHP fatal errors in unrelated modules

I just checked the schema of search_api_clir. It is correct:

        limit:
          type: integer
          label: 'Limit'

I did some more debugging and it turned out that the field in question isn't limit but slop which belongs to search_api_solr:

slop:
    type: float
    label: 'When using the regex fragmenter (hl.fragmenter=regex), this parameter defines the factor by which the fragmenter can stray from the ideal fragment size (given by hl.fragsize) to accommodate a regular expression.'

    $form['third_party_settings']['search_api_solr']['highlighter']['regex']['slop'] = [
      '#type' => 'number',
      '#step' => .1,
      '#min' => 0,
      '#title' => t('regex.slop'),
      '#description' => t('When using the regex fragmenter, this parameter defines the factor by which the fragmenter can stray from the ideal fragment size (given by fragsize) to accommodate a regular expression. For instance, a slop of 0.2 with fragsize=100 should yield fragments between 80 and 120 characters in length. It is usually good to provide a slightly smaller fragsize value when using the regex fragmenter.'),
      '#default_value' => $settings['highlighter']['regex']['slop'],
    ];

The issue seems to be caused by the recent changes to XNumber::getDecimalDigits() which gets called with float 0.5 in this case:
https://git.drupalcode.org/project/xnumber/-/commit/b3c60cfe763bcd65e631...

Thanks for reporting.

The reason is that xnumber whenever possible relies on string numbers which actually you get while using a number form widget in the UI.

I've fixed it and now trying to add more tests for saving non-string numbers programmatically on entity field.

@mkalkbrenner

I created custom valid step and min and max constraint validators. So now saving xnumber value programmatically works the same as doing it from the UI.

Also, I added to the XnumberFieldTest a few lines to save an integer or float (non-string) value on entity xnumber field.

Please check it in your environment and if it's okay I will create 2.0.0-beta1 release.

Adjusted the runRandomNumberDecimalFieldTest() method to newly added constraints.

This is for xdecimal filed stress testing using random generated value, min and max.

I think it might be overhead to run this method each time in automatic testing but for debugging purposes you can change "run" prefix for "test" and see what happens.

Okay, now the module has a great test coverage so there shouldn't be bugs anymore.

Closing it.

Automatically closed - issue fixed for 2 weeks with no activity.