Closed jbrzusto closed 7 years ago
This happens when a burst detected before the nominal activation starts a tag candidate at the SINGLE tag_id_level, and adding the tag demotes it to MULTIPLE tag_id_level, but maintains it as an active candidate. This is a minor issue: we should get at most one pre- activation detection in the run, and it won't be too far back in time. Trying to prevent this would require versioning the DFA graph so that existing candidates at the single confirmation level would continue to follow the original graph when the latter was modified by addition of a new tag. Hardly seems worth the trouble!
This issue was only noticed because it led to many runs of unambiguous tags having tagDepProjectID unset. That more significant problem can be solved by allowing some slop in deployment time
for assigning projectID. When allowing a 20 minute slop in tag deployment time,
only 8 out of 1290440 runs of real tags could not be assigned a tagDepProjectID
:
MariaDB [motus]> select * from runs where motusTagID > 0 and tagDepProjectID is null;
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
| runID | batchIDbegin | tsBegin | tsEnd | done | motusTagID | ant | len | tagDepProjectID |
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
| 106839 | 8 | 1498206547.9259 | 1498206607.6563 | 1 | 25169 | 1 | 2 | NULL |
| 109189 | 8 | 1498294349.7439 | 1498294469.052 | 1 | 25169 | 1 | 3 | NULL |
| 109206 | 8 | 1498294990.186 | 1498295183.965 | 1 | 25169 | 1 | 4 | NULL |
| 112319 | 8 | 1498385651.1464 | 1498385785.3664 | 1 | 25180 | 4 | 3 | NULL |
| 579046 | 41 | 1487272503.6707 | 1487272586.3943 | 1 | 22057 | 4 | 2 | NULL |
| 730317 | 45 | 1479911675.085 | 1479911757.8929 | 1 | 22057 | 6 | 2 | NULL |
| 1189627 | 59 | 1496101785.6944 | 1496101860.3699 | 1 | 25187 | 3 | 2 | NULL |
| 1190124 | 59 | 1496749993.2235 | 1496750022.8969 | 1 | 22057 | 3 | 2 | NULL |
+---------+--------------+-----------------+-----------------+------+------------+-----+-----+-----------------+
8 rows in set (1.11 sec)
This presumably indicates another problem, but we defer investigation for now. The case of tag 25169 in the table above disappeared on rerunning; perhaps metadata changed.
e.g.: Tag 15584 is being detected 45 seconds before its deployment time: