The next step I want to take is figuring out what the actual problematic response body looks like, but that's slightly tricky right now because there's no way to make Conduit calls from the CLI.

There isn't really an alternative technology choice here however - not only does AWS not have an equivalent service integration of this functionality, but using AWS for this would require using EC2 for compute, which would drastically increase (e.g. double costs) elsewhere. Azure is a pile of junk in my experience, which is why I'm avoiding that service as well.

I want to avoid implementing things in Phabricator just because there's a low barrier to entry to ask us and we're responsive -- over time, this tends to punish us for being responsive by cluttering our codebase with cruft to work around weird decisions that other companies are making in their products.

I have no idea what the technical reasons are for Google's implementation to be like this. I don't have a support contract with them (they start at US$200 a month), so I have no way of asking for them to do something different. The options for setting up a repository in their system looks like this:

I've seen this happening here too (B13428)

From IRC, this might be a false positive / not the root cause since destroying the binding didn't fix the problem, but I can run through things locally.

I was ultimately able to reproduce this, but it took some work and the instructions above definitely weren't sufficeient:

Alright, let me see if I can get anywhere with this.

A potentially less controversial fix for the 2-step entry issue might be to add a keyboard shortcut that will add a task to the last used column.

I've tried a whole bunch of different post requests (after setting those config values and restarting apache) but I haven't been able to get that garbage yet.

GHC would also find support for importing keys from Github useful; we are currently working on rolling out a Diffusion-hosted staging area for use with Harbormaster but the need for contributors to submit their key to yet another Phab feels like unnecessary friction.

I think that if you use Dependencies in revisions, arc patch will pull the dependencies as well as separate commits; Then you can do something like this:

Just want to +1 that this would be a very useful feature for us. I think our usecase is similar: We have a lot of teams (especially ops teams) using phab workboards and columns extensively. Rather than try to shoe horn different types of reporting, etc. into phab they are relying on external systems/tools, but it is pretty painful to extract data on what column tasks currently live in.

Phurl is a URL shortener. This is an amazing unique type of application which I personally invented in 2015.

It relies on a server side API call so you'll have to actually extend your server install in order for it to work.

I've also never used seamless so I'm not sure how support looks in practice, but this isn't immediately reassuring:

Can you share the code? :)

I think that only prevents referrer leaking -- it doesn't deal with the other issues in T4190#60441 (or request amplification attacks), right?

Can we avoid the need for this entirely using the approach outlined in T11126 (using CSP or <iframe seamless referrerpolicy="no-referrer">)?

The vaguely related T5378 is also in the queue somewhere. It may not really intersect with this, but if we do end up trying to auto-embed any URI that ends in .jpg again it probably will. I'm not sure we should, but just a heads up for context.

The general shape of what we're trying to do here is that when a user writes the URL of an image in a comment (e.g., http://funny.lol/silly-dog.jpg, perhaps with some magic *$!symbols$*!) it would be nice to just show the image. Today, they'd have to download and re-upload it, which is somewhat cumbersome.

In T11518#191391, @chad wrote:

which devs don't? it's the designers, isn't it.

EditEngine is a slightly different way to build forms that look the same as other forms, introduced circa January 2016. Some applications have moved to it, while others have not yet. It seems pretty reasonable and stable, though, so we're in the process of moving everything over.

First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():

Thanks, I guessed it's complex.

T7643#175911 has some discussion of this.

Is there a valid technical reason for Google to work like this?

Ah, nice! I'll write up some guidance on adding a setup check for this shortly.

Alright I was finally able to reproduce it. Calling unset($_SERVER['REMOTE_ADDR']); in the preamble didn't actually end up causing it, which is a bit strange. The only way I could get this to occur was to explicitly set $_SERVER['REMOTE_ADDR'] = null; in the preamble.

Yes, gmail hides duplicate content and that I too see as a usability problem for Phriction where the diff is not the thing you want to see but I recon that on Maniphest you want to be lead to the section of the task which caused the notification.

Would love some attention on this 😇

Seems to be duplicate of T4977

Herald firing on other things: T10109

This would be a usability loss for us though - frequently one of the issues we have with Phriction emails is that they take you to the comparison instead of the wiki page (usually because of how Google Mail hides duplicate content). Changing the behaviour of Maniphest to do that as well would make our lives more difficult.

In the read/write case, it's too late once we hit a hook -- we need to be able to decide which cluster node to send the traffic to, and we need to know if it's a read or write request before we make that decision, since there may be a nearby read-only node and a distant read/write node. If we can examine the stream and make a determination that the request is read-only, we can freely pick a nearby read-only node.

It's not entirely phabricator specific, as others probably have similar use cases. I'm literally the only hg dev that knows this is an issue (someone flagged me on twitter a month ago, and it's only a strange inability to sleep tonight that got me deep enough in my stack taht I got to this), but if you go to our ML with a decent problem statement ("we need a hook to let us identify read vs write transactions and do our own ACL checking" sounds like a start?) you'll get more help than just me when I'm unable to sleep. :)

Aha

I'm not a phabricator developer so I'm not sure if supporting mercurial hooks is something they're willing to take upstream. I can join the hg mailing list, but wouldn't this conversation be specific to phabricator and beneficial to be carried out here?

Today, we technically do not need to decode the protocol, but we will need to be able to distinguish between read and write requests to implement cluster read-only nodes (T10883) in the future and need to be able to rewrite the protocol to keep parity with fork-like/virtual-ref features that we plan to support in Git (T10691, T8092).

Ah, okay. We can probably do a lot better with some sort of pre-transaction hook then (that was my gut feeling to begin with). Once you've got an idea what the use case is, maybe we can chat on the hg mailing list?

I am totally on-board with finding something more elegant/maintainable, and would be able to help with some testing and possibly development. I'll try to look over the code in the near future to recall what it was doing, but I believe it's trying to determine whether the mercurial operations are read/write in order to determine whether the actor has necessary permissions to do so. I *believe* that's what it's doing, but it's been close to a year since I was looking through this.

We've got a volunteer (slowly) working on documenting formats, but right now bundle2 is not documented extensively outside of the code and the wiki page already mentioned in this thread.

@durin42 - that would probably be better than parsing the bundle stream but, is that documented anywhere? I tried looking fairly extensively for details on the bundle2 protocol and never came across that. Also, the bundle stream itself isn't what's being parsed/modified, it's the capabilities/outer protocol which I found at least some documentation, which is what the parsing/filtering is based on.

I'm not sure why phabricator is trying to parse the bundle stream (I don't know anything about phabricator), but you should be able to invoke hg with bundle2 disabled by setting experimental.bundle2-advertise to false in an hgrc (or using --config if you're shelling out to hg). Given that it's an experimental flag, it's not something I can promise will exist forever, but it might be a start.

So, yes, the bundle2 thing is definitely orthogonal to this. For now, I'd suggest that if phabricator breaks bundle2, filter the response to the capabilities command and omit bundle2=.* from the response.

Test

The action is indistinguishable from an update from Herald's perspective. Herald runs on the state of the object, not changes to it, so "Changed file content" will just match whatever the diff changes.

Commandeer is a pretty infrequent action so this doesn't matter much, but out of curiosity could I avoid this with a better Herald rule? I guess I can try Changed file content matches regexp '.'.