serhiy-bzhezytskyy opened a new pull request, #20:
URL: https://github.com/apache/solr-orbit-workloads/pull/20
### Description
Two defects in `nyc_taxis/workload.py`'s standard value sources. Both are
unreachable today, and both become reachable together: a value source is only
ever called from `QueryRandomizerWorkloadProcessor`, and query randomization is
a silent no-op on Solr's string queries (apache/solr-orbit#75, fixed by
apache/solr-orbit#76). This should land with that.
**1. `random_money_values` passes a float to `random.randrange`**
```python
gte_cents = random.randrange(0, max_value*100) # 111.98 * 100 ==
11198.000000000002
```
`random.randrange` rejects a float outright from Python 3.12 on, and
solr-orbit requires 3.12 or later, so `total_amount_source()` raises on every
supported interpreter and the `range` operation cannot draw a bound at all:
```
TypeError: 'float' object cannot be interpreted as an integer
nyc_taxis/workload.py:33 gte_cents = random.randrange(0, max_value*100)
```
Measured on two interpreters: 3.9.6 accepts the float silently, 3.12.4
raises. Rounding to whole cents keeps the bounds on the two-decimal grid the
function already returns; over 20,000 draws the highest upper bound is 111.97,
still inside 111.98.
**2. `date_source_without_hours` never covers its last day**
It names whole days and wrote both bounds at `T00:00:00Z`, into queries
whose upper bound is exclusive. So the upper day was cut at its first instant.
Two consequences.
The last day is lost. On 300,649 documents, `2015-03-10` through
`2015-03-12` matched 1,698 documents where it should match 2,623; the
difference is exactly the 925 documents dated `2015-03-12`. Upstream OpenSearch
rounds a date-only `lte` to that day's last millisecond, so the same randomized
range covered a day less here than there.
Worse, when both bounds land on the same day the query matches nothing. Over
100,000 draws the two bounds are equal 16,229 times, so one randomized
`date_histogram_facet` query in six would be
```
dropoff_datetime:[2015-01-14T00:00:00Z TO 2015-01-14T00:00:00Z}
```
and report a latency for a query that reads no documents.
The fix advances the upper bound to the following day's first instant, which
is the rule the fixed bounds in `operations/default.json` already follow and
does not depend on how fine Solr's date precision is. Over the same 100,000
draws no pair of bounds is equal, and the highest upper bound is `2015-01-15` —
inside `date_histogram_facet`'s facet window, which ends `2015-01-22`, so this
needs nothing else to be correct.
### Measured
With apache/solr-orbit#76 applied and this branch checked out, against Solr
10.0.0 with 300,649 documents: 240 randomized queries over the five operations
that register a value source, four seeds. All HTTP 200; `sum(bucket counts) ==
numFound` for every one, 0 violations; no empty date query at all, where the
shipped code gives one in six.
One query in the 240 still matches nothing — `trip_distance:[5 TO 5}`. That
is `trip_distance_source` drawing the same integer twice, and upstream produces
it just as often from `gte: 5, lt: 5`, so I left it alone rather than diverge.
### Issues Resolved
Neither has an issue of its own; apache/solr-orbit#75 describes why both
were invisible. This does **not** close apache/solr-orbit-workloads#12 —
widening the randomization range to the whole year is a separate change, and it
needs nothing from here.
### Testing
This repository has no test suite (#14), so both changes were verified by
execution against a live Solr, as above. Each commit carries its own
measurement.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
