test: Add §3.4 range-cap and §7.3.1 Step.Name job conformance fixtures - #155
test: Add §3.4 range-cap and §7.3.1 Step.Name job conformance fixtures#155leongdl wants to merge 1 commit into
Conversation
| # Template Schemas 3.4: a task parameter's range may take on at most 1024 | ||
| # values. A user-SUPPLIED RANGE_EXPR value is only expanded at job creation, | ||
| # so the cap must be enforced there: "1-1025" expands to 1025 values and job | ||
| # creation must fail, even though the template itself is valid. |
There was a problem hiding this comment.
This sounds wrong, range expressions are not limited the same as range values. I remember we made sure the range expression wording didn't include that limit, seems like we need to amend that wording to be clear that the range limit does not apply.
| steps: | ||
| - name: EchoStepName | ||
| let: | ||
| - banner = 'step-is-' + Step.Name |
There was a problem hiding this comment.
Interesting, since this let is executed at step scope, and can access Step.Name
There was a problem hiding this comment.
Quorum verdict: NOT-GOOD (5/5) — spec: §3.4.1.1.1 <IntRangeExpr>.
Upstream commit 3069673 added normative text: the number of values an <IntRangeExpr> expands to "is not constrained by this specification", and the §3.4.1.1 1024-element cap "does not apply to this form" — a >1024-value expansion is the motivating use-case (see the new mainline fixture 3.4--wide-int-range-expression.yaml, which accepts 1-5000). This fixture pins rejection of a supplied RANGE_EXPR "1-1025", i.e. the opposite of current spec. A conformant implementation exits 0 and fails the test; a non-conformant one passes for any rejection reason. Recommend: drop, or invert to an acceptance fixture.
There was a problem hiding this comment.
Quorum verdict: GOOD-WITH-NITS (5/5) — spec: §3.4.1.1 <IntRangeList> max 1024 elements (accept side at exactly 1024, via whole-field LIST[INT] resolution).
Nits: (1) header cites "RFC 0006" for typed whole-field resolution — that mechanism is RFC 0005 / Expression Language §1.3.2 (RFC 0006 is the function library); (2) header wording "the range cap is at MOST 1024 values" conflates the capped list form with the now-uncapped expr form (post-3069673) — scope it to the list form; (3) consider whether a resolved list[int] inherits the literal-list cap at all — the spec doesn't state it explicitly; (4) ~3 min runtime on the Python CLI for two substring assertions; the 1024-int one-line literal is hard to review.
There was a problem hiding this comment.
Quorum verdict: GOOD-WITH-NITS (4/5; 1 dissent NOT-GOOD) — spec: §3.4.1.1 list-form 1024-element cap, rejection side at 1025.
Majority reads the resolved-list value as filling the <IntRangeList> form, which remains capped post-3069673, so rejecting 1025 is correct and doesn't over-constrain (the uncapped path is <IntRangeExpr>). Dissent: the spec never explicitly says the literal-form cap applies to a whole-field-resolved list, and §3.4.1.1.1's philosophy says implementations should bound task count with their own limits — worth an explicit spec sentence either way. Nits: same "RFC 0006" misattribution (should be RFC 0005 / EL §1.3.2); header generalizes "a task parameter's range may take on at most 1024 values", which is false for the expr form — reword.
There was a problem hiding this comment.
Quorum verdict: GOOD (3 GOOD / 2 GOOD-WITH-NITS) — spec: §7.3.1 Step.Name available in the Step Template scope incl. stepEnvironments; §3.6.2 StepTemplate.let may reference Step.Name with bindings visible in stepEnvironments.
All assertions carry the exact resolved value (EchoStepName / step-is-EchoStepName), so a wrong or unresolved value can't pass by substring accident. Fills a real runtime gap: existing coverage was static-only or onRun-only. Nit: header cites "RFC 0007 7.3.1" — Step.Name comes from RFC 0005 (the section number is the Template Schemas wiki's); RFC 0007 is parameter types.
|
Quorum review (5 independent agents: spec-literalist, adversarial, test-craft, service-compat, coverage). Per-fixture verdicts posted as file comments. Net: 1 NOT-GOOD, 2 GOOD-WITH-NITS, 1 GOOD. Blocking item: |
c745815 to
4348402
Compare
|
Quorum-review fixes applied and pushed (rebased onto mainline 3069673):
Verified: all 4 fixtures pass against openjd-rs built from upstream/main |
| - EXPR | ||
| name: TestJob | ||
| parameterDefinitions: | ||
| - name: Frames |
There was a problem hiding this comment.
If we have a range, we do not limit the number of items. If given a list, we constraint to 1024.
The total number of tasks are only limited by the the implementation.
| Values: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511, 512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657, 658, 659, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 683, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696, 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708, 709, 710, 711, 712, 713, 714, 715, 716, 717, 718, 719, 720, 721, 722, 723, 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 750, 751, 752, 753, 754, 755, 756, 757, 758, 759, 760, 761, 762, 763, 764, 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787, 788, 789, 790, 791, 792, 793, 794, 795, 796, 797, 798, 799, 800, 801, 802, 803, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838, 839, 840, 841, 842, 843, 844, 845, 846, 847, 848, 849, 850, 851, 852, 853, 854, 855, 856, 857, 858, 859, 860, 861, 862, 863, 864, 865, 866, 867, 868, 869, 870, 871, 872, 873, 874, 875, 876, 877, 878, 879, 880, 881, 882, 883, 884, 885, 886, 887, 888, 889, 890, 891, 892, 893, 894, 895, 896, 897, 898, 899, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 930, 931, 932, 933, 934, 935, 936, 937, 938, 939, 940, 941, 942, 943, 944, 945, 946, 947, 948, 949, 950, 951, 952, 953, 954, 955, 956, 957, 958, 959, 960, 961, 962, 963, 964, 965, 966, 967, 968, 969, 970, 971, 972, 973, 974, 975, 976, 977, 978, 979, 980, 981, 982, 983, 984, 985, 986, 987, 988, 989, 990, 991, 992, 993, 994, 995, 996, 997, 998, 999, 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1015, 1016, 1017, 1018, 1019, 1020, 1021, 1022, 1023] | ||
| expected: | ||
| output: | ||
| - TASK:0 |
There was a problem hiding this comment.
List case - as expected should pass.
Four fixtures pinning create-time and run-time behavior that no existing
fixture covered, updated for the §3.4.1.1.1 spec fix (IntRangeExpr
expansion is uncapped; only the <IntRangeList> form carries the 1024 cap):
- 3.4--range-from-list-param-at-limit.test: exactly 1024 list-resolved
range elements must be accepted (list-form cap, accept side).
- 3.4--range-from-list-param-too-long.invalid.test: a supplied LIST[INT]
of 1025 items through a typed whole-field range "{{Param.Values}}" is
decode-clean but must fail at job creation (list-form cap, reject side).
- 3.4--range-expr-supplied-value-beyond-list-cap.test: a supplied
RANGE_EXPR "1-1025" must be ACCEPTED and run 1025 tasks — IntRangeExpr
expansion is explicitly unconstrained by the spec (3.4.1.1.1). Replaces
the earlier .invalid fixture, which pre-dated the spec fix and asserted
the opposite.
- 7.3.1--step-name-in-step-environment.test: Step.Name resolves in a
step environment's onEnter/onExit, directly and via step-level let.
Review: quorum-review fixes — corrected RFC citations (whole-field
resolution is RFC 0005 / Expression Language 1.3.2, not RFC 0006;
Step.Name is RFC 0005, not RFC 0007) and scoped all cap language to the
list form.
Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
4348402 to
acb7a01
Compare
2 participants
What was the problem/requirement? (What/Why)
Review of the RFC 0007/0008 implementation stack (openjd-model-for-python #318/#313, openjd-sessions-for-python #333, openjd-cli #230) found two spec-observable behaviors that no conformance fixture pinned — both had silently diverged between the Python and Rust implementations:
"{{Param.Values}}"over aLIST[*]parameter, or a suppliedRANGE_EXPR— are only expanded at job creation, where openjd-rs enforced the cap but the Python model did not.Step.Nameresolves inside a step environment's actions — the Rust CLI passed this while the Python CLI failed it.What was the solution? (How)
Four fixtures in
conformance-tests/2023-09/EXPR/jobs/:3.4--range-from-list-param-too-long.invalid.test.yaml— suppliedLIST[INT]of 1025 items via a typed whole-field range; decode-clean, must fail at job creation.3.4--range-expr-supplied-value-too-long.invalid.test.yaml— suppliedRANGE_EXPR"1-1025"; decode-clean, must fail at job creation.3.4--range-from-list-param-at-limit.test.yaml— exactly 1024 values accepted (guards the off-by-one an at-the-cap rejection bug would introduce). Note: runs 1024 trivial tasks — seconds on the Rust CLI, ~3 minutes on the Python CLI; the fixture header documents this.7.3.1--step-name-in-step-environment.test.yaml—Step.Nameresolves in a step environment's onEnter/onExit at run time, directly and through a step-levelletbinding. (Negative polarity — Step.Name rejected in job environments — already exists as decode-time.invalidfixtures.)How was this change tested?
All four fixtures validated against both implementations via
run_openjd_cli_tests.py: the openjd-rs release CLI, and the Python CLI running the fixed RFC 0007/0008 branches. Both.invalidtemplates confirmed decode-clean (openjd checkpasses on both CLIs), failing only at job creation.