Bitcoin and Altcoin Wallets 6.2.4

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.



protected mixed $priority = 10

int The priority with which to attach to cron action.


protected mixed $task_start_time = 0

int Timestamp at which this task is starting execution.


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.


protected mixed $verbose = false

boolean Whether to write all log() output to debug log.


private static mixed $start_memory = 0

int Memory used at start of tasks batch execution, measured in bytes.


private static mixed $start_time = 0

int Timestamp at which tasks batch starts execution.



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


Cron task logging.

public final log(string $message[, bool $force = false ]) : void

Migration task is always logged.

$message : string

The string to log.

$force : bool = false

Whether to force log the string, even if no verbose logging is checked.

Return values


public final static register() : void
Return values


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


private static get_cron_interval() : int
Return values


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


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.

Return values

Search results