|
|
@@ -2285,7 +2285,7 @@ Dedupe first, then sort descending, then limit - so the assertion pins the order
|
|
|
"nodes": [
|
|
|
{"id": "n1", "name": "Trigger", "type": "click-trigger", "position": {"x": 0, "y": 0}, "config": {}},
|
|
|
{"id": "n2", "name": "Fixture", "type": "code", "position": {"x": 0, "y": 100},
|
|
|
- "config": {"code": "return { rows: [{id: 'a', score: 3}, {id: 'b', score: 9}, {id: 'a', score: 1}, {id: 'c', score: 5}] };"}},
|
|
|
+ "config": {"code": "return { rows: [{id: 'a', score: 1}, {id: 'b', score: 9}, {id: 'a', score: 7}, {id: 'c', score: 5}] };"}},
|
|
|
{"id": "n3", "name": "Shape", "type": "sort-limit-dedupe", "position": {"x": 0, "y": 200},
|
|
|
"config": {
|
|
|
"inputField": "data.result.rows",
|
|
|
@@ -2309,7 +2309,20 @@ Dedupe first, then sort descending, then limit - so the assertion pins the order
|
|
|
}
|
|
|
```
|
|
|
|
|
|
-Dedupe keeps the first `a` (score 3), leaving b:9, c:5, a:3; sorted descending and limited to two, that is b then c.
|
|
|
+The data is chosen so the fixture actually PINS the order, rather than merely
|
|
|
+agreeing with it. Dedupe keeps the first `a`, which is the LOW-scoring one
|
|
|
+(score 1), leaving a:1, b:9, c:5; sorted descending that is b:9, c:5, a:1, and
|
|
|
+limited to two, b then c.
|
|
|
+
|
|
|
+Run the operations in any other order and the answer changes. Sort first and
|
|
|
+dedupe second would keep the high-scoring `a` (score 7), giving b:9, a:7, c:5
|
|
|
+and a final result of b then **a**. Limit before sort would truncate to a:1, b:9
|
|
|
+and end with b then a. Only dedupe, sort, limit produces `[b, c]`.
|
|
|
+
|
|
|
+An earlier version of this fixture used scores 3 and 1 for the two `a` rows,
|
|
|
+which made first-occurrence-in-original-order coincide with
|
|
|
+first-occurrence-after-sorting - so swapping dedupe and sort produced the same
|
|
|
+answer and the test could not tell them apart.
|
|
|
|
|
|
- [ ] **Step 3: Run it**
|
|
|
|
