move denylist check from loader to the runner verification list #588
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Linked proto pr: helium/proto#362
Moves the denylist check from the loader ( where invalids are dropped ) and into the runner's POC verification list. The denylist becomes a regular verification alongside the existing POC verifications and results in failed reports getting outputted to S3.
If a beacon is verified
valid
then the verifications are executed for each individual witness which and now includes the denylist check. Theiot_poc
file outputted to s3 will include metadata enrichment ( location, elevation & gain) for the beacon report and all witnesses (including for both valid and invalid witnesses) and will now include "DENIED" value for the invalid_reason where applicable.If a beacon is verified
invalid
, all witnesses for that beacon are automatically rendered invalid without any verification checks being run on the witnesses. These invalid beacons will be in theiot_invalid_beacon
files on S3, whilst the invalid beacons will be in theiot_invalid_witness
files on s3. The beacon's invalid reason will be set to DENIED, as will be that of the witnesses. The witnessesparticipant_side
field will be set tobeacon
to indicate they inherit the fail reason from the parent beacon.In this scenario the beacon will now have the inclusion of the metadata enrichment fields but the witnesses will not ( as they are failed automatically without any verification checks and never get as far as checking for gateway info )
Copy of a denied list witness take from iot_poc file on s3
{
"elevation": 17,
"gain": 150,
"hex_scale": 0,
"invalid_reason": 9,
"location": "631297351876270079",
"participant_side": 3,
"received_timestamp": 1691089905009,
"report": {
"data": [
239,
35,
61,
135,
158,
232,
184,
89,
48,
157,
37,
158,
230,
172,
5,
2,
188,
170,
18,
31,
169,
53,
141,
208,
132,
16,
70,
190,
193,
168,
230,
10,
148,
115,
221,
27,
166,
119,
219,
251,
15,
38,
121,
53,
147,
215,
62,
215,
22,
30,
209
],
"datarate": 0,
"frequency": 868500000,
"pub_key": [
0,
85,
177,
144,
172,
73,
106,
126,
231,
181,
29,
143,
15,
76,
161,
167,
214,
235,
129,
46,
249,
28,
95,
88,
174,
174,
63,
29,
179,
102,
157,
134,
212
],
"signal": -970,
"signature": [
48,
69,
2,
32,
77,
51,
210,
116,
69,
239,
222,
234,
235,
226,
144,
137,
162,
70,
30,
185,
24,
166,
118,
246,
243,
151,
183,
213,
61,
103,
103,
49,
17,
190,
248,
146,
2,
33,
0,
157,
177,
203,
146,
100,
97,
74,
168,
153,
228,
5,
52,
0,
217,
123,
251,
221,
211,
222,
84,
232,
173,
89,
111,
28,
228,
164,
47,
42,
4,
212,
155
],
"snr": 48,
"timestamp": 1691089904532604633,
"tmst": 3832218681
},
"reward_unit": 0,
"status": 1
},