CI: `test-fuzzydata` fails when `sample` uses a small `frac`

test-fuzzydata has been failing occasionally as can be seen here: https://github.com/modin-project/modin/actions/runs/3062497807/jobs/4943541816

Stack trace

/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/core/generator.py:379: in generate_workflow
    raise e
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/core/generator.py:367: in generate_workflow
    wf.execute_current_operation(next_label)
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/core/workflow.py:197: in execute_current_operation
    raise e
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/core/workflow.py:168: in execute_current_operation
    new_artifact = self.current_operation.execute(new_label)
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/core/operation.py:172: in execute
    result = self.materialize(new_label)
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/fuzzydata/clients/pandas.py:114: in materialize
    new_df = eval(self.code)
<string>:1: in <module>
    ???
modin/logging/logger_decorator.py:128: in run_and_log
    return obj(*args, **kwargs)
modin/_compat/pandas_api/latest/base.py:255: in sample
    return self._sample(
modin/logging/logger_decorator.py:128: in run_and_log
    return obj(*args, **kwargs)
modin/pandas/base.py:2451: in _sample
    return self._default_to_pandas(
modin/logging/logger_decorator.py:128: in run_and_log
    return obj(*args, **kwargs)
modin/pandas/base.py:431: in _default_to_pandas
    result = getattr(self._pandas_class, op)(pandas_obj, *args, **kwargs)
/usr/share/miniconda3/envs/modin/lib/python3.8/site-packages/pandas/core/generic.py:5438: in sample
    size = sample.process_sampling_size(n, frac, replace)

[suhailrehman]

@pyrito These are precisely the kinds of errors I wanted this project to surface! Thanks for digging in!

I haven’t been monitoring this modin integration heavily. But I have some free time this week, and I think I can make some improvements to help improve the testing/debugging experience):

1. I think the same workflow should run on both dask and ray (right now, it’s generating two separate random workflows running on ray and dask, respectively)
2. Artifacts are not being written out on failure (significant pain to rerun and verify if the bug has been fixed)
3. fuzzydata should also run the workflow against pandas to measure performance regressions - maybe if the scale factor is significant enough to warrant it - the primary focus right now is correctness and not performance.

[pyrito]

@mvashishtha @suhailrehman I spent some time digging into the fuzzydata code base and I don’t think the issue is there. Rather, I think we are hitting a very, very specific edge case in how Modin handles sample. If you see here: https://github.com/modin-project/modin/blob/eca9a936846faa31b116a1e58b1114d90cfa44d8/modin/pandas/base.py#L2439, it’s actually possible to end up getting n to be 0, so it’ll end up executing the wrong code path that has n and frac set.