FWIW, I find it hard to believe it's unrelated to recent dask related changes. The test, while quite hairy,

• has no reason to generate dtype=object
• was not generating dtype=object until recently
• today, does not generate dtype=object on anything other than dask.

Not a regression in array-api-compat, nor array-api-tests, nor dask.
I could not find out what started it.

>>> start, stop, step = 0., -9_131_138_316_486_228_481, -92_233_720_368_547_759
>>> da.arange(start, stop, step)

NotImplementedError: An error occurred while calling the arange method registered to the numpy backend.
Original Message: Can not use auto rechunking with object dtype. We are unable to estimate the size in bytes of object data

dask does not support float parameters.

dask internally multiplies step * 100 to divine the dtype, which in turn sends step beyond the limit of int64, which in turn triggers edge case behaviour on behalf of numpy:

>>> np.arange(start, stop, step * 100)
array([0.0], dtype=object)

Ouch. So the right fix is to limit the range for step that moster of a hypothesis test, apparently.

A first shot could be to add one more assume, like assume(abs(step) < M // 2) to
https://github.com/data-apis/array-api-tests/blob/master/array_api_tests/test_creation_functions.py#L133
?

Generally adding assumes makes it more likely to get hypothesis health check warnings, but maybe we'll be lucky here.

The input is legal though. This is a bug in dask.
The last person to touch it was... myself, seven years ago: dask/dask#3722

dask/dask#11707 fixes it upstream