Withdrawals_Task
extends Task
in package
Cron task abstract class.
Concrete implementations of a task must extend this and implement run();
Applications can use $this->log() for logging.
Table of Contents
- $name : mixed
- $priority : mixed
- $task_start_time : mixed
- $timeout : mixed
- $verbose : mixed
- $currency : mixed
- $current_day : mixed
- $start_memory : mixed
- $start_time : mixed
- $withdrawals_batch : mixed
- __construct() : mixed
- Constructor hooks this task into the cron job action.
- log() : void
- Cron task logging.
- register() : void
- run() : void
- Do the task.
- get_cron_interval() : int
- mark_withdrawals_as_done_for_now() : void
- Mark withdrawals as done for now.
- mark_withdrawals_as_pending_again_if_not_modified() : void
- Mark withdrawals that haven't been touched as pending again.
Properties
$name
protected
mixed
$name
string The name of this task.
$priority
protected
mixed
$priority
= 10
int The priority with which to attach to cron action.
$task_start_time
protected
mixed
$task_start_time
= 0
int Timestamp at which this task is starting execution.
$timeout
protected
mixed
$timeout
= DEFAULT_CRON_TASK_TIMEOUT
How many seconds this task is allowed to run. The task's run() method must respect this limit.
$verbose
protected
mixed
$verbose
= false
boolean Whether to write all log() output to debug log.
$currency
private
mixed
$currency
= null
$current_day
private
mixed
$current_day
= ''
$start_memory
private
static mixed
$start_memory
= 0
int Memory used at start of tasks batch execution, measured in bytes.
$start_time
private
static mixed
$start_time
= 0
int Timestamp at which tasks batch starts execution.
$withdrawals_batch
private
mixed
$withdrawals_batch
Methods
__construct()
Constructor hooks this task into the cron job action.
public
__construct() : mixed
Call this after your sub-class constructor.
This way, any changes you make to $this->priority will have an effect.
WARNING: If you forget to call parent::__construct();, your task will not run.
Return values
mixed —log()
Cron task logging.
public
final log(string $message[, bool $force = false ]) : void
Migration task is always logged.
Parameters
- $message : string
-
The string to log.
- $force : bool = false
-
Whether to force log the string, even if no verbose logging is checked.
Return values
void —register()
public
final static register() : void
Return values
void —run()
Do the task.
public
run() : void
Concrete implementations must do the work here in chuncks. The max execution time, usually about 15 or 30 secs must be eenough for all the tasks. So be careful!
Return values
void —get_cron_interval()
private
static get_cron_interval() : int
Return values
int —mark_withdrawals_as_done_for_now()
Mark withdrawals as done for now.
private
mark_withdrawals_as_done_for_now() : void
Here we do a quick SQL hack to update all pending withdrawals as done in one go on the DB. We keep the in-memory status as pending for now. The adapter will later decide if the withdrawals are done, pending, or failed, and the plugin will save the transaction status again.
We do this because, if the adapter succeeds to create a transaction, but takes too long to respond, and the HTTP session times out before the DB is updated, then the funds will be sent out and the user balance will not decrease, but the withdrawal will be reattempted on a later cron run.
So we assume, for now, that the withdrawal will be successful.
On the other hand, if a withdrawal is marked as "done" on the DB, and is not actually executed before the session times out or crashes, then this is bad, but can be recovered from, since no funds were sent. An admin can find the withdrawal that is done without a TXID, and set its status to pending again, manually.
The downside to this is that the user must see the problem and complain to the web admin. But it's still better than allowing double-spent funds, which cannot be recovered from, what with the blockchain being immutable and all.
TL;DR It's better to err on the side of caution on this one!
Return values
void —mark_withdrawals_as_pending_again_if_not_modified()
Mark withdrawals that haven't been touched as pending again.
private
mark_withdrawals_as_pending_again_if_not_modified() : void
We have forced the DB state of all pending withdrawals to be "done" for safery reasons.
We now go through all the withdrawals that haven't been modified in-memory by the adapter, and we reset their DB state to "pending".
Any withdrawals that have been modified in-memory by the adapter, such as successful or unsuccessful withdrawals, will be saved to the DB using their Transaction->save() method.