json read error: too big integer

[Napsty]

I created a script to parse availability reports from Nagios / Icinga but under some circumstances due to wrong downtime calculation, a huge integer appears as value. jshon then fails to parse the entire json output with an error "too big integer".

# curl -s -u user:pw "http://icinga.example.com/cgi-bin/icinga2-classicui/avail.cgi?show_log_entries=&host=internet&service=HTTP+mysite.example.com&assumeinitialstates=yes&assumestateretention=yes&assumestatesduringnotrunning=yes&includesoftstates=no&initialassumedhoststate=0&initialassumedservicestate=0&timeperiod=lastmonth&backtrack=8&jsonoutput" | jshon -k
json read error: line 31 column 1350: too big integer near '18446744073709548794'

As you can see from the json output below, the problem comes from the value of field time_critical_unscheduled inside the avail/service_availability/services array.

{ "cgi_json_version": "1.11.0",
"icinga_status": {
"status_data_age": 15,
"status_update_interval": 10,
"reading_status_data_ok": true,
"program_version": "r2.6.1-1",
"icinga_pid": 18010,
"timezone": "CEST",
"date_format": "us",
"program_start": 1522738805,
"total_running_time": "0d 0h 13m 32s",
"last_external_command_check": 0,
"last_log_file_rotation": 0,
"notifications_enabled": true,
"disable_notifications_expire_time": 0,
"service_checks_being_executed": true,
"passive_service_checks_being_accepted": true,
"host_checks_being_executed": true,
"passive_host_checks_being_accepted": true,
"obsessing_over_services": false,
"obsessing_over_hosts": false,
"check_service_freshness": true,
"check_host_freshness": true,
"event_handlers_enabled": true,
"flap_detection_enabled": true,
"performance_data_being_processed": true
},
"avail": {
"service_availability": {
"services": [
{ "host_name": "internet",  "host_display_name": "internet",  "service_description": "HTTP mysite.example.com",  "service_display_name": "HTTP mysite.example.com",  "time_ok_scheduled": 134221,  "percent_time_ok_scheduled": 5.018,  "percent_known_time_ok_scheduled": 5.081,  "time_ok_unscheduled": 2504799,  "percent_time_ok_unscheduled": 93.644,  "percent_known_time_ok_unscheduled": 94.815,  "total_time_ok": 2639020,  "percent_total_time_ok": 98.662,  "percent_known_time_ok": 99.895,  "time_warning_scheduled": 0,  "percent_time_warning_scheduled": 0.000,  "percent_known_time_warning_scheduled": 0.000,  "time_warning_unscheduled": 0,  "percent_time_warning_unscheduled": 0.000,  "percent_known_time_warning_unscheduled": 0.000,  "total_time_warning": 0,  "percent_total_time_warning": 0.000,  "percent_known_time_warning": 0.000,  "time_unknown_scheduled": 0,  "percent_time_unknown_scheduled": 0.000,  "percent_known_time_unknown_scheduled": 0.000,  "time_unknown_unscheduled": 0,  "percent_time_unknown_unscheduled": 0.000,  "percent_known_time_unknown_unscheduled": 0.000,  "total_time_unknown": 0,  "percent_total_time_unknown": 0.000,  "percent_known_time_unknown": 0.000,  "time_critical_scheduled": 5590,  "percent_time_critical_scheduled": 0.209,  "percent_known_time_critical_scheduled": 0.212,  "time_critical_unscheduled": 18446744073709548794,  "percent_time_critical_unscheduled": -0.106,  "percent_known_time_critical_unscheduled": -0.107,  "total_time_critical": 2768,  "percent_total_time_critical": 0.103,  "percent_known_time_critical": 0.105,  "time_undetermined_not_running": 0,  "percent_time_undetermined_not_running": 0.000,  "time_undetermined_no_data": 33011,  "percent_time_undetermined_no_data": 1.234,  "total_time_undetermined": 33011,  "percent_total_time_undetermined": 1.234,  "total_time_all": 2674799,  "percent_total_time_all": 100.000,  "percent_known_time_all": 100.000,
"log_entries": [
{ "start_time_string": "03-01-2018 00:59:04",  "start_time_timestamp": 1519862344,  "end_time_string": "03-01-2018 02:32:40",  "end_time_timestamp": 1519867960,  "duration_string": "0d 1h 33m 36s",  "duration_timestamp": 5616,  "entry_type": "SERVICE DOWNTIME START",  "state_type": "",  "state_information": "Start of scheduled downtime"},
{ "start_time_string": "03-29-2018 17:00:00",  "start_time_timestamp": 1522335600,  "end_time_string": "03-31-2018 23:59:59",  "end_time_timestamp": 1522533599,  "duration_string": "2d 6h 59m 59s+",  "duration_timestamp": 197999,  "entry_type": "SERVICE OK",  "state_type": "HARD",  "state_information": "HTTP OK: HTTP/1.1 200 OK - 8697 bytes in 0.304 second response time"}
]

}
]
}
}
}

I came across similar bug reports across other json projects (tc39/proposal-bigint#24, akheron/jansson#8), so this seems to be a json parsing problem in general. Is there a way to fix this in jshon or to simply ignore such a value, e.g. by returning 'int_too_big' ?