We had an issue with recurring alert subscriptions disappearing after approx. two weeks, so we started calling the SetAlert service every once in a while with 0 as date_start and date_end. But now we receive duplicate flight alerts. I guess the SaveAlert service can’t be treated as an upsert service? We experienced a similar issue where we had to re-register our callback endpoint after two weeks.
Is there an expiration date associated to an alert subscription (and registered webhook endpoint)?
To perform an upsert, you must ensure that you are calling SetAlert and specifying alert_id = -1. If you specify alert_id = 0 (or do not specify that argument), then it will unconditionally insert.
There is also no reason why alerts would be stopped/deleted after 2 weeks as long as you had created the alert as an indefinite time period (date_end not set to a non-zero time; additionally ident must be given as a tail number or airline with flight number, and not a unique faFlightID).
Thanks for the clarification. We’re now experiencing the following error, when setting the alert_id to -1:
Backend processing error (2020-01-15T11:44:53)
The error code describes a DB SQL syntax error. Let me know if I should include the entire SOAP request/response.
We’ve located the specifics of these failures and are analyzing them further now. No need to supply the request/response to us.
Thanks for looking into it. Do you have an estimated time frame for a fix?
We expect to be deploying a minor change this afternoon, which we don’t expect will fix it but should provide us with additional diagnostic information needed to make further progress next week.
Can you confirm that you are still getting errors from SetAlert? I’ve been checking the recent logs and don’t see any failures like the one you originally described. If necessary, re-attempt whatever logic you were doing at the time. Thanks.
Sure, I reproduced the error by replaying the same request a few times between 2020-01-29T08:44:00 and 2020-01-29T08:45:00.
A fix has been identified and will go live tomorrow (Thursday) afternoon.
Is there any cause for other users with push alerts to be concerned about with respect to this thread, or is the issue result of unique/unusual fringe-case behavior?
The specific bug was limited to use of invoking SetAlert with the alert_id of -1 (indicating an upsert operation on the m_ident argument).
Alerts should not expire or be automatically deleted prior to their date_end.