One of your developers has broken your REST API output

Hi,

One of your developers has broken your REST API output, so that a query without a sensor filter no longer gives a null output for index 12, the "sensors" field.  Instead, it incorrectly gives a list of all sensor IDs even when no filtering for the sensor was used in the request.

Needless to say, this change has broken parsing of the data obtained with a standard query.

For example, use of your example query:
opensky-network.org/api/states/all?lamin...7.8229&lomax=10.5226

Now incorrectly gives:["3c5ef8","EWG2822 ","Germany",1634748722,1634748722,8.5503,46.7884,7010.4,false,171.05,183.1,0,[-1408233453,-1408234987,-1408234283,-1408234539,1408233257,-1408237161,-1408233705,-1408234728,-1408233894,970501013,90188,-1408234466,1433774459,1539466573,-1408236928,2106064085,1208480659,-1408233468,-1408233083,960481128,-1408237048,1516942451,2100459881,1977010121,80389995,-1408232909,1434571365,-1408235788,-1408234186,1805971594,-1408236994,80602915,-1408235905,1805967060,-1408234527,-1408234331,-1408233817,-1408234200,758475469,206281911],7315.2,"0122",false,0],["46b823","AEE853 ","Greece",1634748722,1634748722,8.5625,47.455,null,true,8.75,67.5,null,[-1408237048],null,null,false,0]

As you know, your API specification for the sensors field is: "IDs of the receivers which contributed to this state vector. Is null if no filtering for sensor was used in the request".
I am hoping that you can quickly fix this.  Now that you know about this problem, I suspect the fix will be quick and easy.

Thanks in advance and Best Regards!!

No problem, thanks for the reply! I always say if a day goes by without my making at least one coding error, then I am not doing enough coding. Mistakes are inevitable as long as we humans are part of the process.

Thanks again and good luck with all. OpenSky is amazing, and all of your team's hard work is very much appreciated!

This bug causes a huge increase in bandwidth, and that cannot be good for system performance.

Here is a typical single aircraft record from "states", taken just now from the REST API output, with the bug still present:

["aa56b8","UAL2317 ","United States",1635087453,1635087453,-76.4773,39.7557,10447.02,false,207.89,236.51,-5.2,[-1408232368,-1408233901,-1408233323,970505937,-1408234405,-1408233852,-1408232951,-1408235763,-1408237234,970514683,-1408232525,-1408233928,-1408233543,1408236164,-1408235039,-1408236891,-1408237211,1805987731,-1408235098,-1408232857,-1408237079,-1408234903,-1408235926,970515234,-1408232854,-1408237014],10706.1,"1762",false,0,4]

and this is what that same record would be if the bug had not appeared, or had been corrected:

["aa56b8","UAL2317 ","United States",1635087453,1635087453,-76.4773,39.7557,10447.02,false,207.89,236.51,-5.2,null,10706.1,"1762",false,0,4]

Multiply this difference in data size for a single aircraft record by the average number of aircraft downloaded per data request times the volume of data requests that you get in a day and you can see that the severity of the effect of this bug on overall bandwidth used by your server(s) is very large!  In addition there is the adverse effect of this bug on the bandwidth for each individual user at his/her/their location and the adverse effect of the increased bandwidth on every portion of the path between your server(s) and each and every user.

So addressing this bug is important from a community standpoint, including the broader internet community and not only the OpenSky community.

As a side note, your REST API documentation at opensky-network.org/apidoc/rest.html does not contain documentation regarding the inclusion of a new field [17] in the "states" array which as you can see above is now present in your REST API output.  It would be beneficial to users to add this change to the documentation..

I'll add another example just taken from the REST API output stream here.  This record from the current output (with the bug):

["4841a8","TRA5427 ","Kingdom of the Netherlands",1635099491,1635099492,7.661,47.6954,12496.8,false,234.74,156.36,0,[-1408233453,-1408236394,-1408233705,1434525323,1435907100,-1408234466,1433774459,-1408234338,-1408234337,934459296,-1408233597,-1408234492,1208480659,-1408233083,-1408237048,1516942451,1977010121,80389995,-1408232909,1805974151,-1408234186,91305,970500210,90925,2098002593,1805971594,-1408232413,-1408234332,-1408234331,-1408232409,-1408236377,-1408233817,-1408234200,954776276,-1408234159,-1408233388,-1408234283,-1408234539,1408233257,1801273114,42064840,-1408233894,91083,970501013,-1408233890,333333392,970510088,333333391,333333900,2106064085,-1408233661,960481128,852742020,1408234672,-1408235661,-1408235788,1434571365,-1408232583,-1408235909,-1408232580,1035116639,80602915,-1408235905,1805967060,-1408233501,693642540,-1408234394,758475469,81483681,206281911,-1408236946,956030212],12687.3,"0177",false,0]

becomes, without the bug:

["4841a8","TRA5427 ","Kingdom of the Netherlands",1635099491,1635099492,7.661,47.6954,12496.8,false,234.74,156.36,0,null,12687.3,"0177",false,0]

There are many similar examples from a single download of the REST API dataset in its current iteration.

Thanks! It is fixed and performance is excellent!