/api/point returns invalid JSON (bare NaN literals)

[jakobbuis]

OpenTAKServer's /api/point endpoint sometimes emits bare NaN literals where a number is expected, producing a body that is not valid JSON. Strict JSON parsers (e.g. Dart's jsonDecode, Python's json.loads, browser JSON.parse) reject the response with a syntax error.

Example

Excerpt from a real response on a paginated GET /api/point?sort_by=timestamp&sort_direction=desc&per_page=1000:

"ce": NaN,
(at line 13765, character 13). 

The same response contains many well-formed numeric ce values; only some rows surface NaN.

Expected

Per RFC 8259 §6, NaN and Infinity are not valid JSON. The server should either:

• emit null (or omit the field) when the value is unrepresentable, or
• emit a JSON-spec-compliant alternative such as the string "NaN".

Actual

Bare NaN is written into the JSON output, breaking any standards-compliant client.

Likely cause

Python's stdlib json module emits NaN/Infinity by default (allow_nan=True). If the response is built with json.dumps(...) or Flask's jsonify(...) over a value that ended up as float('nan') (often from a NumPy/SQL conversion of a NULL numeric), this is the result. Setting allow_nan=False would raise at serialization time so the bad value can be sanitized; alternatively, sanitize floats to None before serializing.

Workaround on the client

We currently regex-replace bare NaN/Infinity literals with null before parsing, but this should not be necessary for a JSON API.

Affected endpoints

Confirmed on /api/point. Likely affects any endpoint that surfaces float columns; worth auditing /api/markers, /api/eud, /api/cot, etc.

[brian7704]

The only way I was able to reproduce this issue was to manually insert a row in the points table with the ce field set to NaN. I'm guessing there was an unusual CoT message where the ce attribute was either NaN or something else that's not a number. I'll see if I can check for that and insert a null into the database instead.