On my mobile device (an iPhone 4S), I think it's slightly faster to tap-wait-tap-copy the URL bar than press-hold-copy a link.

This report doesn't describe a bug.

This should now be resolved in production.

We have an additional safety check which is supposed to prevent this kind of issue: we refuse to process messages with the same "Message-ID" more than once.

@paladox, we appreciate your enthusiasm but I think you have a very mistaken set of expectations about the kinds of services we provide. See some discussion in Support Resources.

We don't plan to support this in the upstream. We have a system in a similar role already (Harbormaster) and would prefer to expand it to do more if there is missing functionality.

I think this is happening:

Thanks for the report, D15573 should fix this. Sorry about that!

See Support Resources.

No, badges themselves don't have an awarder.

I know you guys want reproduction steps

jx-tooltip is a free spirit :3

This should now be resolved in HEAD of master. I've deployed the change here, and verified I can interact with the comment in D15565.

I think a workaround is to swap the particular changeset into unified mode (View Options → View Unified) and then interact with the comment, but the fix seems trivial and straightforward.

Thanks, I can reproduce this as well (e.g. D15565).

Too many deck slots, product literally unplayable.

FUN POLICE HERE

This is fairly messy and probably not worth fixing until the surrounding code is more modernized.

T7805 was the "use applicationsearch in the dialog" task.

I think this default ("all my open stuff") is probably the right one for "Edit Dependencies" and "Edit Maniphest Tasks" from Differential, and for "Edit Blocking Tasks", "Edit Pholio Mocks" and "Edit Differential Revisions" in Maniphest, although the argument for some of those is a little weaker.

In my flow I essentially only ever merge by copying the task ID, so the filter doesn't matter at all. Do you tend to search for the task by name?

Ah, interesting. I wasn't aware it was gone in PHP7. Given that, I agree that this probably isn't worth supporting (I've never seen this syntax in the wild myself).

Sounds good. I added you to Community so you should have sweeping administrative powers now.

The more modern, slightly more concise process is:

I'm thinking for my case, there's not really a lot of value in keeping the tags around after the diff has been closed. Maybe that's something to consider?

I probably wouldn't show them in the UI for now, although I don't think adding an "Other Refs" table underneath tags/branches on the main screen with, say, 5 entries and a "See All" button would necessarily be terrible if anyone can come up with a reason that users might ever care about it.

User profile images should be getting cached. For example, your profile image here:

Sounds good. Let us know if you run into anything else.

You can register an event listener for the TYPE_AUTH_WILLREGISTERUSER event. We are generally moving away from this system, but it works today and I don't have any near-term plans to replace it in this case. This is the documentation:

I haven't been successful locally in getting a GC'd node to reach an appreciable level of memory consumption, and the production servers are currently at ~1.5GB.

I think the ~1.5GB node instance size is also expected.

In T10350#167753, @rbalik wrote:

This is useful, but are there any plans to add this functionality to the GUI? Would be nice to have for when we're doing some housekeeping

See T10350.

Sorry, Vehicle VIN Identification Numbers.

(It mostly has reference stuff like our vehicle VIN numbers, our PG&E account number and credentials, etc. If you hack it, you can pay our electric bill!)

There is, but we don't use it very much.

At least locally, I can't manage to get node to not leak:

Oh, and as an unusual special case I'll upstream anything you want to do to PhabricatorRepositoryManagementEditWorkflow and we'll keep it not-broken until T10337, although I promise to break it after that. This workflow has special favor and exists outside the normal rules of usptreaming hacks.

You can also just update the JSON value in the details column in phabricator_repository.repository directly. This won't generate a proper transaction in the edit record, but will work correctly (that column is authoritative, and not cached by anything).

This would be strictly obsoleted by T10337 and not help us build toward it, so we'd prefer not to pursue it in the upstream.

To actually do forking, the pathway is roughly:

We can do "private branches", but you can already do something like this:

We're seeing a lot of connections stick in "R" ("Reading Request") for a long time, but the client is the load balancer and the request hasn't been read yet so it's not clear exactly what's going on with these. I think they may be crawlers, since pretty much every search engine loves indexing everything on this install hundreds of times an hour.

I'm fiddling with LB health checks, so it's my fault if the server vanishes.

Per T9293, client-uri and server-uri should be split into client-port, client-host, admin-port and admin-host.

I'll make a note on T10697 to split these options into explicit host and port options. The use of uri options which combined hosts and ports was intended to make specifying hosts and ports more convenient, but I think it's clear that it was a grievous error.

MaxRequestWorkers 24 appears to be creating some issues. This host only serves about 5 requests/second, but I can hit delays with concurrency of 10 (e.g., ab -n100 -c10):

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

See T10326.

I plan to make these options explicit instead. This tangled maze of inferring things from various values is a bad state of affairs. See T10697.

To resolve this, configure your server so that $_SERVER['HTTPS'] is set correctly. This impacts other checks, so it is much better to fix it than try to guess our way around it by examining aphlict.client-uri.

This doesn't describe a reproducible problem. See Providing Reproduction Steps.

I plan to separate this configuration and make these options all explicit, see T10697.

The Aphlict logs don't reveal anything useful, and could use some attention: they're heavily geared toward setup/debugging, not maintenance/operations.

I've deployed a MaxRequestWorkers 24 change to this server and wasn't able to get it to burst over 24 workers with ab, so that seems to be working. I'll keep an eye on it for the rest of the week, and the 48 limit will go out to the cluster later this week if no problems turn up.