Querying by authorPHIDs works.

Thanks for info!

Broadly, this behavior is expected.

Usually we are restarting builds on Jenkins if they failed due some environment issue. For example connection problems or git misconfiguration. If other words if build failed not because of code changes in diff, we restart build on Jenkins.

Is Jenkins restarting the build automatically, or is a human going into Jenkins and clicking "restart"?

I don't plan to pursue this. We'll offer JS access to the OAuth API instead (see T7303).

See above.

It's very hard for us to prioritize work which doesn't actually solve real problems, or where we don't understand the greater need. This is why we ask users to describe problems and avoid hypotheticals in the guide describing how to file good feature requests.

What are you trying to accomplish?

What are you trying to accomplish?

I don't plan to pursue this. I consider it highly desirable that users must explicitly grant permission to OAuth clients.

Use arc call-conduit, not arc install-certificate.

arc install-certificate --conduit-token api-XXXXXXXXX

Does not work. It still prompts for an API token instead of taking in the cli parameter.

Use --conduit-token.

This is not resolved because the web interface to generate api tokens does not generate cli tokens that arc install-certificate asks for.

I think T9132 is the most promising approach for reducing the complexity in exposing transaction writes in a general way.

We currently allow any message, we just don't do anything with messages we don't understand. Possibly this should be made more strict, but I imagine accepting any message and possibly letting extensions handle them in the future. We might not be able to figure out if anything will accept a message or not when we receive it.

I'm not sure where you want this typeahead?

Okay, can you file a separate issue for that and I'll try to reproduce it? That's bad and not the expected queue behavior.

Generally we find that the commit / message parser tasks tend to get done first, and take up taskmasters that could be processing Harbormaster builds. This delays builds because we have less taskmasters available.

commits without UTF8 data in them effectively block the queue.

@epriestley Is there an ETA on this? It's been 7 days since I cleared out failing Git parser tasks and there's another 20 I need to clear out now. This issue has a significant impact on our background processing because commits without UTF8 data in them effectively block the queue.

We don't plan to restore actAsUser in any form to the upstream, since it violates policies and can not be made safe (in the sense of not-policy-violating).

Thanks chad. It is not require you to support our code, but confirming if there is any bug in API, or how to use API.

This generally falls outside what we provide free support for:
https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#supported-issues

any findings？ it blocks us for a internal tool.

No. If there was, it would be posted here.

Are there any news about this issue?

FreeBSD has very strong interest in this sort of API call. It would permit us to integrate better with certain systems that are not part of phabricator. It also makes writing a migration script entirely against conduit feasable.

good !

but when I passed a string, error again. and actually when I create task in page, we can select multiple users.

The error message says it expects a string and you are passing an array.

anyone looking at this?
I attached log file.

In T8722#123856, @epriestley wrote:

Is there a stack trace for that error in your error log (often /var/log/apache2/error.log or similar)?

That's not an error I recognize.

Is there a stack trace for that error in your error log (often /var/log/apache2/error.log or similar)?

Yeah, the diff contains invalid UTF8:

Well, I think we're in a bad position, because this code:

to line 27 of AphrontJSONResponse (right after it constructs the JSON), shows:

to line 147 of PhabricatorConduitAPIController shows that the diff content does pass through this line at least once.

Adding file_put_contents('/tmp/diff3', $result); on line 92 of PhabricatorConduitAPIController.php shows that the result is still correctly stored at this point.

at line 136 of DiffusionQueryConduitAPIMethod on the storage tier results in the file having the diff content, so the issue must be further on than this.

When I change line 119 of DiffusionQueryConduitAPIMethod.php to:

I'm like 95% sure this has something to do with the content of the actual diff returned, like UTF-8 encoding or something like that...

Something is totally whack with the cluster configuration in the latest HEAD. For some reason, the storage tier is now constructing a Conduit client to code.pageuppeople.com, even though it should just run the command locally. Even worse, the $is_cluster_request variable is set to true, yet it still constructs a new Conduit client.

For some reason, the storage tier is attempting to forward the request on to another machine inside the cluster (presumably itself?) and is then recursing. This makes no sense given that the code in src/applications/diffusion/conduit/DiffusionQueryConduitAPIMethod.php at line 123 is designed to prevent recursion.

I ran the query directly against the Conduit API on the storage machine, from my local machine, and it returns an empty response (so it's got nothing to do with the requesting machine):