You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I couldn't find any instance of the ignore_user_abort PHP function when grepping the code. To me, that signifies a user must wait until every page loads and every request fully completes (which can be a long time for big sends with a small machine), and they can never get a network interruption nor a power failure, otherwise PlaySMS will simply crash and be left in an inconsistent state (e.g. a stuck queue). For read operations it doesn't matter but write operations should complete unless the user sends a "stop doing that" request to the app. I can see why one would want to be able to cancel a send, but surely that should be done explicitly rather than closing a browser tab and hoping for the best.
Sends could be cancelled by deleting the relevant outbox records and .txt files, then changing the queue's flag field. It's a simple thing to add but then creates challenges if you want to allow control of, or present status information on currently processing requests.
This isn't just theoretical, we've had large sends (as in tens of thousands of messages) fail because of this. I've had to manually clean up the database after.
The text was updated successfully, but these errors were encountered:
I couldn't find any instance of the
ignore_user_abort
PHP function when grepping the code. To me, that signifies a user must wait until every page loads and every request fully completes (which can be a long time for big sends with a small machine), and they can never get a network interruption nor a power failure, otherwise PlaySMS will simply crash and be left in an inconsistent state (e.g. a stuck queue). For read operations it doesn't matter but write operations should complete unless the user sends a "stop doing that" request to the app. I can see why one would want to be able to cancel a send, but surely that should be done explicitly rather than closing a browser tab and hoping for the best.Sends could be cancelled by deleting the relevant outbox records and
.txt
files, then changing the queue'sflag
field. It's a simple thing to add but then creates challenges if you want to allow control of, or present status information on currently processing requests.This isn't just theoretical, we've had large sends (as in tens of thousands of messages) fail because of this. I've had to manually clean up the database after.
The text was updated successfully, but these errors were encountered: