mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-28 01:32:42 +01:00
857e3aee83
Summary: Ref T2222. Five very small improvements: - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable. - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value. - Add an additional check for the other case (shouldn't have a value, but does). - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong. - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions. Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4557, T2222 Differential Revision: https://secure.phabricator.com/D8401
20 lines
475 B
PHP
20 lines
475 B
PHP
<?php
|
|
|
|
final class PhabricatorApplicationTransactionStructureException
|
|
extends Exception {
|
|
|
|
public function __construct(
|
|
PhabricatorApplicationTransaction $xaction,
|
|
$message) {
|
|
|
|
$full_message = pht(
|
|
'Attempting to apply a transaction (of class "%s", with type "%s") '.
|
|
'which has not been constructed correctly: %s',
|
|
get_class($xaction),
|
|
$xaction->getTransactionType(),
|
|
$message);
|
|
|
|
parent::__construct($full_message);
|
|
}
|
|
|
|
}
|