I’ve come across a potential small bug/issue in SimpleQ that I thought I would feed back to you.
After running an upgrade on Monday I realised that the file needed to be reauthorised with my main iCLINICIAN file and that around 800 messages had a status of 2. Failed Permanently. Once I’d reauthorised I used the Retry button on a couple of the queued messages. Most worked but I had one type that continued to fail. After stepping through the process I realised this was because the last error in the iCLINICIAN script being run was a 401, no matching records. However, this was not a problem with the message being delivered or the script completing so should therefore be 1: Delivered shouldn’t it?
If I am correct, do you think the $processError script step in the btn Retry script needs to be modified to account for an error like a 401 which isn’t actually an error with the message?
What you want to do here is to make sure that your subscriber script returns a zero error code when there isn’t an error.
There is no way for SimpleQ to know if a 401 is a problem or not. It would depend entirely on the script. So deciding if 401 is a problem or not is up to the script itself. If it isn’t a problem then return 0 for the code. If it is, then return 401.
Most errors will fail permanently if you pass them back. The exceptions are for things that are transient, like 301 record locking.
If your script’s last executed step returns an error with Get(LastError) then SimpleQ will pick that up.
So the simplest thing is to make sure that doesn’t happen for cases when it isn’t an error that you want SimpleQ to pay attention too. Make your script do something else that isn’t an error. Some people have a standard of setting a $variable to “” at the end of all their scripts just to avoid this sort of thing.
Also SimpleQ recognizes the FM Data API json error Format. So if you exit your script with something like