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.

Properties

$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.

$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.

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.

Tags
throws
Exception
Return values
void

Search results