Per spec, randomize accepts an optional seed. The current implementation currently checks that the seed is an integer, and throws (a string, a tangentially related my-bad) if it's not. This was derived from the implementation in OpenRosa XPath Evaluator, so I'd expect this bug affects Enketo as well. Which is somewhat surprising, because I discovered the bug by using XLSForms' prominent example for stable-randomization.

Steps to reproduce

1. Use the aforementioned XLSForms example in a form

Expected behavior

1. A form using a decimal/float seed to randomize will stably randomize options, without error
2. Even if there is an error due to an actually invalid seed value, it will be surfaced to the user in some meaningful way
3. Possibly some sort of recovery behavior for certain invalid seed values (like NaN or ""?), but this would potentially involve spec clarification

Observed behavior

(From memory, happy to repro again if needed) Form load fails without explanation.