{
 "tokens": {
  "input": 39642,
  "cache_read": 52794,
  "cache_write": 2933,
  "output": 16349
 },
 "reviews": [
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz",
    "main aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:70:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse]\n     aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:67:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1\n     aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:70:12: note: Condition 'wlen<=len' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`wlen` is `min(feedseq, len)`: when `feedseq > len` it gets `len`, otherwise it gets `feedseq`, which is `<= len`. So `wlen <= len` is always true, and the warning is a true positive. The `else` branch is dead code. The PR turned the `?` handling in `valueFlowImpossibleValues` into an `else if`. The preceding branch (most likely the unsigned impossible-value one) now matches the unsigned `size_t` ternary first, so the symbolic `< len+1` value is never set and the warning is lost."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz",
    "main aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:88:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse]\n     aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:85:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1\n     aria2-1.37.0/deps/wslay/tests/wslay_event_test.c:88:12: note: Condition 'wlen<=len' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "On line 85, `wlen` is set to `feedseq > len ? len : feedseq`, which is min(feedseq, len). So `wlen <= len` on line 88 is always true. The warning was a genuine true positive, and it points at a real logic slip: the else branch is dead code, and `<` was probably intended. The PR turned the `?` handling in valueFlowImpossibleValues from `if` into `else if`, chaining it to the preceding block. That appears to stop the impossible-value/symbolic bound being set for this ternary, so the correct warning is lost."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz",
    "main aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:67:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse]\n     aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:64:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1\n     aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:67:12: note: Condition 'wlen<=len' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`wlen` is assigned `feedseq > len ? len : feedseq`, so `wlen <= len` is always true. The warning is a true positive. The PR turned the `?` handling in valueFlowImpossibleValues into an `else if`. For an unsigned (`size_t`) ternary, the preceding unsigned-minimum branch already matches, so the symbolic bound from the `?` branch is no longer set. The `|` handling the PR adds is unrelated to this code. Losing this correct warning is a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/a/aria2/aria2_1.37.0+debian.orig.tar.gz",
    "main aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:81:12: style: Condition 'wlen<=len' is always true [knownConditionTrueFalse]\n     aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:78:47: note: Assignment 'wlen=df->feedseq[df->seqidx]>len?len:df->feedseq[df->seqidx]', assigned value is less than symbolic=len+1\n     aria2-1.37.0/deps/wslay/tests/wslay_frame_test.c:81:12: note: Condition 'wlen<=len' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`wlen` is computed as `feedseq > len ? len : feedseq`, which is min(feedseq, len). So `wlen <= len` really is always true, and the removed warning was a true positive (the else branch is dead code). The PR turned the `?` handling in valueFlowImpossibleValues into an `else if`. The preceding block most likely handles unsigned expressions (it sets an impossible lower bound), and this ternary is `size_t`. So that block now consumes the token and the ternary's symbolic impossible value (`len+1`) is no longer set. As a result the valid knownConditionTrueFalse warning is lost."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/clearsilver/clearsilver_0.10.5.orig.tar.gz",
    "main clearsilver-0.10.5/util/dict.c:264:23: style: Condition 'hash!=(unsigned int)-1' is always true [knownConditionTrueFalse]\n     clearsilver-0.10.5/util/dict.c:261:25: note: Assignment 'hash=dict->hash(id)%65536', assigned value is less than 65536\n     clearsilver-0.10.5/util/dict.c:264:23: note: Condition 'hash!=(unsigned int)-1' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`hash = dict->hash(id) % DICT_HASH_BITS` (65536) stores a value below 65536 in an unsigned 32-bit variable. So `hash != (UINT32)-1` (0xFFFFFFFF) really is always true, and the removed warning was a true positive. The PR only meant to add impossible-0 values for `|`. It also rewrote the `%` branch and turned an `if` into `else if`, and this unintended change lost a correct knownConditionTrueFalse warning. The exact cause is unclear, but losing a correct warning is a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/d/dino-im/dino-im_0.5.1+git20260802.baea516.orig.tar.xz",
    "main dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:191:25: style: Condition 'pad_len==0' is always false [knownConditionTrueFalse]\n     dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:190:26: note: Assignment 'pad_len=16-(plaintext_len%16)', assigned value is greater than 0\n     dino-im-0.5.1+git20260802.baea516/plugins/omemo/src/native/helper.c:191:25: note: Condition 'pad_len==0' is always false"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`plaintext_len % 16` is in [0,15], so `pad_len = 16 - (plaintext_len % 16)` is in [1,16] and fits in uint8_t. `pad_len == 0` can never be true, so main's warning was a true positive; the check is dead defensive code. The PR changed `if` to `else if`, which joins the `%` branch to the earlier if-chain. A `%` token that matches the earlier branch (likely the unsigned/size_t case) no longer gets the impossible lower-bound value, so this true positive is lost."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/k/kannel/kannel_1.4.5.orig.tar.gz",
    "main gateway-1.4.5/test/drive_smpp.c:284:37: style: Condition '(id%enquire_interval)==0' is always true [knownConditionTrueFalse]"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "low",
    "explanation": "Main reported `(id % enquire_interval) == 0` as always true. For that, Cppcheck must have known `enquire_interval` as a constant, most plausibly 1, since only then is an unsigned `id % n` always 0. The definition of `enquire_interval` is not shown, so this is an inference. The PR is meant to add impossible values for `|`, but it also turned the `?` handling into an `else if` and rewrote the `%` match. Losing this warning looks like a side effect of that restructuring, not a fix for a false positive. If `enquire_interval` really is never changed from 1, the removed warning was a true positive, so this is likely a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libe/libevtx/libevtx_20251118.orig.tar.gz",
    "main libevtx-20251118/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libevtx-20251118/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libevtx-20251118/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libevtx-20251118/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true\n     libevtx-20251118/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, once `remaining_size == 1` is false, `remaining_size == 2` must be true, so the removed warning was a true positive (the else-if is redundant). The PR turned the `?`/`%` handling into an `else if` attached to the earlier branch in valueFlowImpossibleValues. That earlier branch most likely handles unsigned expressions, and the `size_t % 3` result is unsigned. If so, the `%` branch is now skipped and the impossible 'value >= 3' bound is never set, so the correct warning is lost. The same happens at line 2672."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libe/libevtx/libevtx_20251118.orig.tar.gz",
    "main libevtx-20251118/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libevtx-20251118/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libevtx-20251118/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libevtx-20251118/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true\n     libevtx-20251118/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`remaining_size = byte_stream_size % 3` is in [0,2]. Inside `if (remaining_size != 0)`, after `else if (remaining_size == 1)`, the check `remaining_size == 2` is always true. The warning that main reported is therefore a true positive. Its loss looks like a side effect of the PR changing the `?` branch into an `else if` chained to the previous `if` in valueFlowImpossibleValues. That change alters which branch handles the `%` token, so the impossible-value bound on the `%` result is no longer set. Losing a correct knownConditionTrueFalse warning is a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libf/libfsfat/libfsfat_0~20260208.orig.tar.gz",
    "main libfsfat-20260208/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `remaining_size != 0` and after the `remaining_size == 1` branch, `remaining_size == 2` really is always true, so the removed warning was a true positive. The PR changed `if` to `else if` before the `?`/`%` handling in valueFlowImpossibleValues. The earlier branch (likely the unsigned non-negative impossible value) now prevents the `%` upper-bound impossible value from being set for this size_t expression. That logic change, not better understanding of the code, is why the warning was lost."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libf/libfsfat/libfsfat_0~20260208.orig.tar.gz",
    "main libfsfat-20260208/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true\n     libfsfat-20260208/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`remaining_size = byte_stream_size % 3` is always 0, 1 or 2. Inside `if (remaining_size != 0)`, once `== 1` has been ruled out, `remaining_size == 2` really is always true, so the warning is a true positive (a redundant check). The PR changed the `if` for the `?` case to `else if`. That ties the `?` / `%` / `|` branches to the preceding unsigned-value branch in valueFlowImpossibleValues. For an unsigned expression such as `size_t % 3`, the unsigned branch now runs and the `%` branch (impossible value >= 3) is skipped. The upper bound is lost and the true positive disappears, which is an unintended side effect of the change."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libo/libolecf/libolecf_20240427.orig.tar.gz",
    "main libolecf-20240427/libuna/libuna_base64_stream.c:2423:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libolecf-20240427/libuna/libuna_base64_stream.c:2419:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libolecf-20240427/libuna/libuna_base64_stream.c:2411:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libolecf-20240427/libuna/libuna_base64_stream.c:2413:21: note: Assuming condition is true\n     libolecf-20240427/libuna/libuna_base64_stream.c:2423:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, once `remaining_size == 1` has failed, `remaining_size == 2` must be true. So the removed knownConditionTrueFalse warning was a correct true positive. The PR changed the `?` handling from `if` to `else if`, which pulls the `%` branch into the earlier if/else chain. When the earlier branch matches the `%` token, the impossible-value bound of 3 is no longer set. The earlier branch is not shown, but it is plausibly the unsigned-type handling, since `byte_stream_size` is a `size_t`. That loses a valid diagnostic, which is a regression unrelated to the PR's intent."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libo/libolecf/libolecf_20240427.orig.tar.gz",
    "main libolecf-20240427/libuna/libuna_base64_stream.c:2672:27: style: Condition 'remaining_size==2' is always true [knownConditionTrueFalse]\n     libolecf-20240427/libuna/libuna_base64_stream.c:2668:27: note: Assuming that condition 'remaining_size==1' is not redundant\n     libolecf-20240427/libuna/libuna_base64_stream.c:2660:36: note: Assignment 'remaining_size=byte_stream_size%3', assigned value is less than 3\n     libolecf-20240427/libuna/libuna_base64_stream.c:2662:21: note: Assuming condition is true\n     libolecf-20240427/libuna/libuna_base64_stream.c:2672:27: note: Condition 'remaining_size==2' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`remaining_size = byte_stream_size % 3` can only be 0, 1 or 2. Inside `if (remaining_size != 0)`, after the `remaining_size == 1` branch, `remaining_size == 2` really is always true, so main's warning is a true positive (redundant style condition). The note 'assigned value is less than 3' shows main relied on the impossible >=3 bound set for `%`. The PR turned the `?`/`%` handling into an `else if` chain after the preceding `if`. When that earlier branch matches the `%` token (likely because the operands are unsigned `size_t`), the `%` bound is no longer set. That fits the loss of this correct warning, so dropping it is a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/m/mupen64plus-video-rice/mupen64plus-video-rice_2.6.0.orig.tar.gz",
    "main mupen64plus-video-rice-src-2.6.0/src/TextureFilters.cpp:383:34: style: Condition 'z%1' is always false [knownConditionTrueFalse]"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`z` is `uint32`, so `z%1` is always 0 and the ternary condition is always false. The removed warning was a true positive, and it points at a real bug: the author probably meant `z%2`. The PR turned the `?` branch into an `else if`, which chains it to the preceding unsigned-token `if` in `valueFlowImpossibleValues`. For unsigned expressions the `%` branch no longer runs, so the impossible `>=1` bound is never set on `z%1`. Combined with the unsigned `>=0` bound, that bound was what let Cppcheck prove the value is 0. The PR therefore lost a true positive through an unintended side effect."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/m/mygui/mygui_3.4.4+dfsg.orig.tar.xz",
    "main MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:161:19: style: Condition 'index==3' is always true [knownConditionTrueFalse]\n     MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:159:19: note: Assuming that condition 'index==2' is not redundant\n     MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:152:34: note: Assignment 'index=(unsigned long)rand()%4', assigned value is less than 4\n     MyGUI-mygui-84c2874/UnitTests/UnitTest_MultiList/UnitTest_List.h:161:19: note: Condition 'index==3' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`index = (size_t)rand() % 4` can only be 0..3. After the checks for 0, 1 and 2, `index == 3` really is always true, so the removed warning was a true positive (even if the explicit check is a readable style choice). The PR turned the separate `if` into `else if`. For an unsigned `%` expression, the earlier branch (likely the one that marks values below 0 as impossible for unsigned types) now runs instead of the `%` branch. So the 'value is less than 4' bound is no longer set, and Cppcheck lost information. This is an unintended side effect, not a fixed false positive."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/n/nng/nng_1.12.4.orig.tar.gz",
    "main nng-1.12.4/tests/multistress.c:767:5: style: Condition 'x>i' is always false [knownConditionTrueFalse]\n     nng-1.12.4/tests/multistress.c:767:5: note: Assignment 'x=rand()%(sizeof(templates)/sizeof(templates[0]))', assigned value is less than 3\n     nng-1.12.4/tests/multistress.c:767:5: note: Assuming that condition 'i>1' is not redundant\n     nng-1.12.4/tests/multistress.c:767:5: note: Condition 'x>i' is always false"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "medium",
    "explanation": "`x = rand() % NTEMPLATES` with NTEMPLATES == 3 gives x <= 2, and the loop condition `while (i > 1)` gives i >= 2, so `x > i` really is always false. The removed warning was a true positive (the check is dead defensive code). The likely cause is that the PR turned the `?` branch into an `else if`. The `%` lower-bound impossible value can now be skipped when an earlier branch in valueFlowImpossibleValues matches the same token. Cppcheck lost knowledge it had before."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/n/nng/nng_1.12.4.orig.tar.gz",
    "main nng-1.12.4/tests/reqstress.c:267:5: style: Condition 'x>i' is always false [knownConditionTrueFalse]\n     nng-1.12.4/tests/reqstress.c:267:5: note: Assignment 'x=rand()%(sizeof(templates)/sizeof(templates[0]))', assigned value is less than 3\n     nng-1.12.4/tests/reqstress.c:267:5: note: Assuming that condition 'i>1' is not redundant\n     nng-1.12.4/tests/reqstress.c:267:5: note: Condition 'x>i' is always false"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`x = rand() % NTEMPLATES` with NTEMPLATES == 3 gives x in [0,2]. Inside `while (i > 1)`, i is at least 2, so `x > i` can never be true. The condition is genuinely always false, so the removed warning was a true positive. The PR turned the `?` handling into an `else if`, which joins it to the preceding `if` in valueFlowImpossibleValues. If that earlier branch matches a `%` token, the `%` bound is no longer set, which would explain why the warning disappeared. Losing it is a regression."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/o/openjpeg2/openjpeg2_2.5.4.orig.tar.xz",
    "main openjpeg-2.5.4/src/lib/openjp2/t1.c:1527:30: style: Condition 'h%4==3' is always true [knownConditionTrueFalse]\n     openjpeg-2.5.4/src/lib/openjp2/t1.c:1525:30: note: Assuming that condition 'h%4==2' is not redundant\n     openjpeg-2.5.4/src/lib/openjp2/t1.c:1527:30: note: Condition 'h%4==3' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`h` is unsigned. Inside `if (h % 4)`, the value is non-zero, and the branches have already ruled out 1 and 2, so `h % 4 == 3` really is always true. The removed warning was a true positive. The likely cause is the PR's change of `if` to `else if` in valueFlowImpossibleValues. Unsigned expressions (such as `h % 4`) are presumably caught by the earlier unsigned branch. They then no longer reach the `%` branch, so they lose the impossible upper bound (value >= 4 is impossible) that let Cppcheck prove the condition. This is an unintended loss of precision."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/q/qt6-3d/qt6-3d_6.11.2+dfsg.orig.tar.xz",
    "main qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:217:20: style: Condition 'extraBytes>0' is always true [knownConditionTrueFalse]\n     qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:199:27: note: Assignment 'extraBytes=3-length%3', assigned value is greater than 0\n     qt3d-everywhere-src-6.11.2/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXUtil.cpp:217:20: note: Condition 'extraBytes>0' is always true"
   ],
   "verdict": {
    "verdict": "regression",
    "confidence": "high",
    "explanation": "`length % 3` is in [0,2], so `extraBytes = 3 - length % 3` is always in [1,3], and `extraBytes > 0` is always true. The warning was a true positive, and it also points at a real logic issue: when length is a multiple of 3, extraBytes is 3, not 0. The PR changed the separate `if` before the `?` branch into an `else if`. As a result, the `%` lower-bound impossible value is no longer set for tokens that already matched the first branch, most likely because the operands are unsigned. Losing that value caused the true positive to disappear."
   }
  }
 ],
 "started": "2026-10-27 07:15:29 UTC",
 "runner": "aws-testrunner-1"
}