"random_score", acceptable values for "seed" changed between 1.3 and 1.x

[iamjochem]

hi there,

we have successfully been using integer representations of javascript Date objects for the "seed" property of the "random_function" scoring function, i.e. output of the following function:

function seedval(max_age) 
{
    var ma = max_age || 60000;
    return Math.ceil(+new Date() / ma) * ma;
}

which results in numbers like:

1414573200000

yesterday a colleague built and installed ES from source using the 1.x branch and stumbled upon the following error (it was definitely referring to the value set for "random_score.seed"!)

JsonParseException[Numeric value (1414573200000) out of range of int

NB: I am not looking for a fix as such (we decided to simply divide our generated seed values by 1000 thereby solving our immediate problem)

I am creating this issue because it just might be something that you would consider to be a regression, I have no idea which of the following might be true ... so by all means close this issue if you consider it to be irrelevant :)

1. we are running ES as a 32bit process (not the case AFAICT)
2. this is an intentional change/fix
3. this is an unintentional change/bug - possibly related to upgrading (or introducing?) the Jackson lib, from which the parse error seems to originate.

hope this is of some use, thanks for reading!

[clintongormley]

@rjernst could you take a look at this please? Looks like https://github.com/elasticsearch/elasticsearch/pull/7446/files changed from long to int.

[jpountz]

I agree it would be nice to fix it as it is common to provide 64-bits values as seeds (eg. timestamps).

Maybe we could internally translate the 64-bits to 32-bits (since we only use 32-bits in practice) in a Long.hashCode fashion? Or maybe we could even allow the seed to be any string and internally use the 32-bits hash of this string as a seed. This could potentially be more user-friendly by allowing users to directly provide things like a session id?