Differential D9637 Diff 23125 src/applications/chronicle/daemon/ChronicleDaemon.php

Changeset View

Standalone View

src/applications/chronicle/daemon/ChronicleDaemon.php

This file was added.

				<?php

				final class ChronicleDaemon extends PhabricatorDaemon {

				public function run() {
				$table = new ChronicleTrigger();
				$table_name = $table->getTableName();
				$conn = $table->establishConnection('r');

				do {
				// Get the next trigger to fire.
				$triggers = queryfx_all(
				$conn,
				'SELECT id, epochNext '.
				'FROM %T '.
				'WHERE epochNext != %d '.
				'ORDER BY epochNext '.
				'ASC LIMIT 1;',
				$table_name,
				ChronicleTrigger::EPOCH_NEVER);

				// If there are no triggers, wait 60 seconds and poll again.
				if (count($triggers) === 0) {
				$this->sleep(60);
				continue;
				}

				// Get the next trigger to fire from the results.
				$next_trigger = $triggers[0];

				// If the next trigger is greater than 65 seconds away, wait
				// 60 seconds and poll again.
				if ($next_trigger['epochNext'] - time() > 65) {
				$this->sleep(60);
				continue;
				}

				// Otherwise, load the trigger object and then wait until it's
				// epoch.
				$trigger = id(new ChronicleTriggerQuery())
				->setViewer(PhabricatorUser::getOmnipotentUser())
				->withIDs(array($next_trigger['id']))
				->executeOne();
				$implementation = $trigger->getActionImplementation();

				// Sleep for the required amount of time.
				$time_to_sleep = $trigger->getEpochNext() - time();
				if ($time_to_sleep > 0) {
				$this->sleep($time_to_sleep);
				}

				// Execute the implementation.
				$implementation->execute($trigger);

				// Recalculate the next epoch.
				$trigger->setEpochNext($trigger->calculateNextEpoch());
				$trigger->save();
				epriestleyUnsubmitted Not Done Inline Actions This is the biggest difference in the two designs: this approach has a huge race window, up to 65 seconds + time it takes to execute the trigger, which may be long. If a user modifies the trigger during these 65+ seconds from the web UI, their changes will be lost after the trigger executes and calls `save()`, overwriting the trigger and reverting it to a state it was in 65 seconds ago. There's also a small race window at the end where a user can load, the daemon saves, then the user saves. In this case, the event will execute twice. That's OK for builds, but not good for email notifications and catastrophically bad for billing. D11419 has more complicated infrastructure, but I believe it prevents the daemon from ever racing against the application. epriestley: This is the biggest difference in the two designs: this approach has a huge race window, up to…

				// Poll again.
				} while (true);
				}

				}