- User Since
- Aug 22 2016, 4:36 PM (21 w, 4 d)
Thu, Jan 19
Mon, Jan 16
ah yep that seemed to work. I was still specifying releaseNotes for the field which I'm guessing is why it wasn't getting saved. Thanks again for all the help! If you're ever in Pittsburgh I think I owe you about 50 beers at this point.
I pulled in that change and I'm still seeing the same issue. Editing the field from /differential/revision/edit/... seems to work normally, but adding it via the differential.createrevision endpoint does not.
Checking in for guidance in case this is the wrong way to go. I have a custom field which extends DifferentialStoredCustomField and I'm trying to convert it in the same way as the above. Thus far my field isn't being saved when calling differential.createrevision. I've included the DifferentialCommitMessageCustomField and the DifferentialStoredCustomField below.
Wed, Jan 11
Thanks that did it! Still working through an issue with one of our more *ahem* exotic applications, but I suspect that'll be a more involved refactor on our end.
Tue, Jan 10
Doing that without defining getFieldTransactions() in my class yields this exception:
Transaction with key "1" has invalid type "devTestPHIDs". This type is not recognized. Valid types are: update, comment, title, summary, testPlan, reviewers.add, reviewers.remove, reviewers.set, repositoryPHID, tasks.add, tasks.remove, tasks.set, view, edit, projects.add, projects.remove, projects.set, subscribers.add, subscribers.remove, subscribers.set, phabricator:auditors.
Thanks for the help Evan. I've gone through and converted everything as you suggested. The conduit method then started telling me
Mon, Jan 9
Dec 9 2016
Choosing "Abandon Revision" because "Abandon Revision, Set it on Fire, and Pretend it Never Existed" isn't an option. I'll get a diff ready that adds that as an option.
Oh god. I step away for 5 minutes and I'm now on the phacility hit-list.
haha I had a feeling this probably fell into the category of things that are in the process of being done a better/holistic way
Dec 6 2016
Dec 5 2016
Nov 22 2016
Use <= rather than <
@epriestley do these changes look alright? I pulled most of PhabricatorWorkerArchiveTaskQuery up into the abstract PhabricatorWorkerTaskQuery and then added PhabricatorWorkerActiveTaskQuery. That made it more straightforward to just AND all the constraints together.
Backed PhabricatorWorkerActiveTasks with an actual query object and refactored to share
some logic between Active and Archived tasks. Also removed some overeager indentations.
Nov 21 2016
Confirmed this on my local. It seems to be due to D16851, specifically this line: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/diffusion/application/PhabricatorDiffusionApplication.php$104.
Nov 10 2016
Pretty sure this works as intended
Yes I did have the persistent chat pane open. Also can't seem to repro without it.
The other errors that appear in DarkConsole:
Oct 28 2016
Oct 14 2016
Oct 13 2016
Hmmm I'm not seeing those lines in that file anywhere. On the current head of master, I'm pretty sure the viewer is always set to PhabricatorUser::getOmnipotentUser() in TransactionPublishWorker. Although maybe that isn't making it all the way to the policy aware query in every case.
Oct 12 2016
@jessjohnson I still haven't had a chance to dig further into this, but I'll report back when I do (or if you figure anything out, please let me know). I don't think killing off the tasks permanently is really an option since this seems to happen for specific degenerate instances of otherwise-needed tasks. Perhaps not allowing these tasks to retry would be an okay bandaid, but I'd still like to figure out the underlying problem if we can.
Oct 11 2016
Nope we don't have that integrated in yet (just missed our last cutoff). Once we get that pulled in I'll confirm it clears up the issue.
Evan, do you think there is a route forward with this that would be feasible for me to implement upstream?
Oct 6 2016
Oct 5 2016
Ah yeah it could be related to that (policy errors/unit test failures), although I wouldn't really describe this as "extremely rare" (except of course when I'm trying to make it happen). Some stats from grepping through logs: since last week it looks like this error has happened 73k times involving 193 distinct diffs. It's like the daemons are laughing at my inability to repro it.
Just spent a bit of time trying to repro this in a script but could not. The diffs always load successfully from the script. I even tried waiting until right after one of the errors popped up in the logs and then queried for that diff via the script right away.
Sep 28 2016
Gonna go ahead and say no one should be automatically subscribed to tokens
Fixed issues brought up in CR
Sep 27 2016
removed another vestige of application names
DELETE MOARRR CODE
Make getRedirectURI always have a domain
Added short URL to results
Added ability to search by URL name substring
Sep 26 2016
Updated based on CR comments
Added parameters for width, height, alt, layout, and href
As far as dealing with URLs where the protocol isn't specified I see a few possible approaches:
Use null rather than empty string.
more succinct alias checking for src key
All of the following syntaxes work now:
Now using the imageproxy endpoint.