Commit 241b6ef
authored
QC-1142 fix object preservation for 1_per_run policy (#2228)
In some cases (e.g. a postprocessing task trending moving windows), the "validFrom" of the created objects might evolve slightly to the past.
This is what we may see at the beginning of run:
I 11 09:25:34.936 check/sink-PTOF_TOFTrendingO1e7a TOF 2mZYw7qfc8t 549286 Validity of MO 'TOFTrendingOrbits' is (1711956219957, 1711956273223)
I 11 09:26:34.055 check/sink-PTOF_TOFTrendingO1e7a TOF 2mZYw7qfc8t 549286 Validity of MO 'TOFTrendingOrbits' is (1711956219854, 1711956333793)
I 11 09:27:34.090 check/sink-PTOF_TOFTrendingO1e7a TOF 2mZYw7qfc8t 549286 Validity of MO 'TOFTrendingOrbits' is (1711956219854, 1711956392709)
On the other hand, the 1_per_run policy tries to sort the objects by "validFrom" and only if they are equal, it sorts them by "createdAt".
Thus, in the discussed case it will preserve the object which is the latest in terms of "validForm", thus the object from the beginning of the run.
This commit fixes 1_per_run policy by relying solely on "createdAt" to find the latest object for a run.
I could not think of any cases when this could not be applied.1 parent a793c24 commit 241b6ef
1 file changed
Lines changed: 9 additions & 8 deletions
Lines changed: 9 additions & 8 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
15 | 15 | | |
16 | 16 | | |
17 | 17 | | |
18 | | - | |
| 18 | + | |
19 | 19 | | |
20 | 20 | | |
21 | 21 | | |
| |||
68 | 68 | | |
69 | 69 | | |
70 | 70 | | |
71 | | - | |
| 71 | + | |
72 | 72 | | |
73 | 73 | | |
74 | 74 | | |
75 | | - | |
76 | | - | |
77 | | - | |
78 | | - | |
79 | | - | |
80 | | - | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
| 79 | + | |
| 80 | + | |
| 81 | + | |
81 | 82 | | |
82 | 83 | | |
83 | 84 | | |
| |||
0 commit comments