Sometimes secondary index functions are getting evaluated with global optargs present.

[srh]

Secondary index function evaluation should not have any global optargs present (or if they did, we'd want the global optargs captured at the secondary index creation -- but that's not how things work right now).

Right, now, at insertion things are fine -- secondary index functions are evaluated without the global optargs present (according to the testing I've done). That's why this is a low priority, v1.14 bug.

However, we can see that queries like table.get_all([2], index='foo').run(right_bound='closed') (with a contrived secondary index function lambda x: x.slice(1,2)) are at some point rerunning the secondary index function in the environment with the global optargs present, affecting their evaluation.

I'm assigning this to myself because I'm already touching some of the code in question (in rget_cb_t::handle_pair).

[srh]

I have implemented a fix in sam_2767. However, I don't know what the best way to write a regression test is. Is there a way to specify the global optargs in a reql test?

[gchpaco]

Yes. See the brand new array limits reql test for a demo.

[srh]

Awaiting review 1829.

[mlucy]

c.f. #2710, I think it's unlikely enough that someone is relying on the old buggy behavior for their queries that we shouldn't offer a way to turn it back on.

[srh]

What does this have to do with #2710?

[mlucy]

There's the same question of "how likely is it someone is depending on this behavior vs. how much work is it to maintain the old behavior concurrently with the new behavior".

[srh]

Issue #2710 does not have anything to do with that question.

[srh]

Issue #2701 is the issue you are probably talking about. That issue is different because there you want to corrupt people's database files.

[mlucy]

Whoops, sorry for the transposition.

(Also, I approved the review.)

[mlucy]

@srh: is this in next?

[srh]

I'm sorry. Yes, it is.