"Call to a member function getPHID() on a non-object" while creating milestone using conduit

Version information:
Using the stable branch

phabricator c4b4a53cad7722f031b725f8b41511e9d341d033 (Fri, Dec 13) (branched from 54bcbdaba94a3573e128c6498816dbfa41d3a9cb on origin) 
arcanist cc850163f30c4697e925df0d6212469679600a2c (Tue, Nov 19) 
phutil 39ed96cd818aae761ec92613a9ba0800824d0ab0 (Sep 30 2019) 

Reproduction steps

1 - Create a Project via UI normally
2 - Use project.search to find project PHID
3 - Send request data to project.edit to create milestone referencing the project PHID
4 - See error message

Sample request using curl:

curl http://phabricator-instance.com/api/project.edit \
    -d api.token=api-lca6qpfpngkpgsrsrkppzuqaivjj \
    -d transactions[0][type]=milestone \
    -d transactions[0][value]=PHID-PROJ-rt4ibxhpq3wc7gk3xyvv \
    -d transactions[1][type]=name \
    -d transactions[1][value]=test_milestone

I tested using a test instance, but the error did not occur, I suspect it might me something related to this Differential review https://secure.phabricator.com/D20920

My test instance: https://test-gukp62gxu4nd.phacility.com

This used to work but some time ago it stopped working, and only now I noticed it

Anyone?

Try updating your instance and checking again?
Also, can you create milestone using the web interface, or does that throw an exception too?

Edit: I have also updated to the lastest avaliable on master and the problem still ocurs.

phabricator
    6ccb6a6463f78e135455332401d2f84950409828 (Thu, Jan 16) 
arcanist
    cc850163f30c4697e925df0d6212469679600a2c (Nov 19 2019) 
phutil
    cc2a3dbf590389400da55563cb6993f321ec6d73 (Tue, Jan 14) 

Hello,

I updated my instance to the newest available on stable and the problem still ocurs.
I can create the milestone using the web interface just fine, the problem only happens when using conduit to do so.

Version info:

phabricator
    c4b4a53cad7722f031b725f8b41511e9d341d033 (Dec 13 2019) (branched from 54bcbdaba94a3573e128c6498816dbfa41d3a9cb on origin) 
arcanist
    cc850163f30c4697e925df0d6212469679600a2c (Nov 19 2019) 
phutil
    cc2a3dbf590389400da55563cb6993f321ec6d73 (Tue, Jan 14) 

Hi,

I’m maintaining the FreeBSD port of Phabricator and a user reported the same issue to me. I spent a few hours digging into the code and found the root cause. I created a fix for the problem, you can download the patch from my forked github repo.

Explanation from the commit log:

Unbreak milestone creation over Conduit API (project.edit).

This addresses a problem reported on the phabricator community web site and on the FreeBSD ports mailing list.

Creation would fail reporting “Call to a member function getPHID() on null”.

The underlying issue was the code introduced in T13462 (diff on github), which aims to set the correct members/policies when creating a milestone. This code relies on the new object to be already initialized with a parent project. When using the user interface, this is done in PhabricatorProjectEditController[4]. When using the Conduit API, this code path isn’t used though, hence the error message when trying to use the null-parent.

This fix catches the problem while creating a copy that is adjusted for policy checks - this seemed the best solution, as it doesn’t mess with anything else and the correction is close to where the problem happens.

Using other mechanisms like overloading applyInitialEffects won’t work, as they happen too late in applyTransactions.

Thanks, I’ve filed this upstream as https://secure.phabricator.com/T13553.

I think your patch is reasonable and won’t cause any significant negative behavior (although its failure behavior when the parent PHID isn’t valid or isn’t visible might not be ideal). The patch should also degrade gracefully once I fix this upstream.

Upstream, I suspect I’ll address this by adding logic to PhabricatorProjectEditEngine->newEditableObjectFromConduit() instead, or by creating some more general variation of that mechanism. See also https://secure.phabricator.com/T13449, which has a similar need to pre-apply “subtype” transactions before performing other validation. Almanac and Drydock also have a “pre-apply” phase today.