I modified diffusion.rawdiffquery to do the following before returning the result:

yeah that does not make sense and would cause nothing to work I'm pretty sure

(Wait I may be crazy.)

The client is doing validation of the response including presence of fields and their type.

This parameter is not required, although the hint should probably say "optional order".

Awesome! Yep, 'type' => 'string' fixed it.

Ah, interesting. I'm glad to hear it's been working out (although I'm a little surprised!).

thanks for the quick replies! internally to uber, arc patch has served us well. we git reset --hard to the base revision, then patch --nocommit --nobranch. it wasn't until we open sourced our jenkins plugin and got this bug report that we even noticed this behavior. i'll follow the task you mentioned and update the jenkins plugin when a more robust solution is available.

Yell if that doesn't actually fix things once it lands, but I'm pretty confident it's the issue.

I'm also not sure how well arc patch handoff has been working for you, but T8090 has some discussion of some more reliable approaches we're evaluating and moving toward.

This is an artifact of the PHP json_encode() method's rules for guessing whether a PHP array is an JSON object or a JSON list.

Thanks! 99% sure that's the fix, then: you're on a 32-bit system and the 'int' type can't represent the 64-bit chronologicalKey.

It's possible that the paging code is breaking somehow, although I still haven't been able to reproduce this and can't see any way it could. Can you log the value of $cursor passed to getPagingValueMap() each time through the loop? It should look like this:

Logging each function call, I'm seeing this:

Not really. But I cobbled something together via the bot, which suggests that this is this stack trace:

(If you can, set debug.time-limit to 10 and then repro it; it should give you a more useful stack trace.)

Can you reproduce this by calling feed.query manually from the web UI?

Just for the records:

Presuming resolved since I'm pretty sure this works properly.

... on the host

I'd exec ssh directly. If there's some major advantage to using libssh2 (but what?), I'd possibly use that optionally if it was available on the host.

@epriestley: If/when this is to be supported in arc, do you imagine using php's libssh2, or execing ssh directly?

Should be fixed in HEAD. Thanks for the report!

This is generally not possible until after T5873.

The settings page when editing bot users should allow the creation of Conduit API tokens

These work fine on desktop, just collapsing on mobile for some reason.

Yeah that's what we were doing actually, but given our environment and arcanist's checks regarding the file permissions (that it's 600, etc.) it was messy due to shell restrictions and other stuff where our scripts are running. This will be great for build agents posting back Harbormaster statuses.

As a goofy workaround you can probably write some dummy file

Great, thanks. It appears that it does still need the certificate in a .arcrc file somewhere, as we removed that file as part of the above test and received the certificate prompt.

I'd expect it to work on relatively up-to-date Phabricator. You may still need to have some valid-ish ~/.arcrc file, which we might be reading and then ignoring. I'll check that and fix it if it's the case -- we shouldn't require a ~/.arcrc if you specify --conduit-token.

Is the above commit able to be used or are there a few steps to go? Gave it a quick try and it still wanted my bot user to install a certificate despite providing an API token with the above parameter.

I actually want both of those tasks.

I'm going to merge this into T5873 (see that task for discussion), but you might really want T3980.

For context, it sounds like https://phabricator.wikimedia.org/T96238 is the root issue here, specifically https://phabricator.wikimedia.org/T96238#1234459. In general:

This is a bug in Phabricator.

Oh, maybe I wasn't clear, sorry! Basically, please update to HEAD and verify you still see a bug. That is all I am asking from you.

But it works for any older branch that can be found here in any older revision. And it worked for us before migration (I don't know which version was before). And now it doesn't work for us, and it doesn't work here for any recent branch.

It's exceedingly rare that we have branches in Phabricator. I think I've seen it twice. We just use master.

@chad, I've just tried to search for herald_queryrules which is a Phabricator branch and no results too. Or please provide me a what you call "a branch on this server/repository" to test, I'll try.

go-unit-engine isn't a branch on this server/repository, at least, I don't expect it to return a result.