Specifically we need steps to reproduce the issue. I don't know what "the pages" means, or where you expect an edit page to be found. We have lots of applications and fields that URIs could be in.

Please read and follow Contributing Bug Reports, we don't accept incomplete bug reports.

Nevermind, found another task. Thanks!

Does this reproduct against an up to date version of Phabricator?

D18069 appears to fix this, but I want to understand where it blames to and possibly pursue a more graceful fix since D18069 feels a little flimsy.

This appears to have been resolved by D18042. I'm letting the mail stuff fall by the wayside for now.

I can't reproduce this at HEAD, so presuming this was resolved by rP7b290b94a7.

It's possible that didn't get everything, but yell if you hit anything else and we can shovel on some more test cases. Thanks for the report!

Thanks for the fixes! Most folks are on Chrome at Dropbox, so Safari being subject to the Heisenprod Uncertainty Principle doesn't worry me much.

This is still not working very well for me in Safari in production, although I don't seem to be able to break it in Chrome or Firefox anymore after a few tries.

Looks like it was deprecated a while ago, without explanation. Luckily, there's --log-junit, which we have some code to parse.

@epriestley yes, the tested owner packages were both weak dominion. Sorry for not mentioning that earlier. You've explained the issue perfectly as far as I can tell. The changes you have planned make a lot more sense than the current behavior and should fix the issues we were seeing. Thank you!

@lvital, I can only reproduce this if use "Weak Dominion". Is that the case in your example, too?

This transaction uses shouldHideForFeed(), which isn't currently supported by Modular Transactions. It got swapped over in D17844 or some related change and we didn't catch that the logic wasn't firing anymore since this is a bit of an obscure case.

My guess is they updated early in the week, saw the broken image, and updated and still saw the broken image. Not that they updated and tested the reproduction steps again.

Thanks, this reproduces here for me.

(This is still on my radar.)

I believe this was fixed by 7b290b94a726f7c9eb3efd9e065499fde1b0ad00. Are you 100% sure that the image was updated after that change?

I think that got things closer but we aren't quite there yet. I'll poke at this a bit more tomorrow.

Possibly fallout from T11784 / D17911, although those shouldn't really interact here unless there are other bugs.

T11997/T12032 look related, but not the same behavior.

Forgot to specify browser: this is Chrome 58.0.3029.110 (64-bit) on OS X and Linux. Also replicates on Safari 10.1.1 (12603.2.4).

For pulls (vs mirrors), we switched to ls-remote to detect no-ops in D17497. The primary motivation was to let us make better clustering decisions, but it also "appeared" to improve performance, which suggests that it may not be outlandish to imagine that git ls-remote would use fewer resources here as well.

Thanks for the detailed response! We hadn't considered that people might tamper with mirror remotes, so you make a very good point there that our proposed change might cause a regression. And you're quite right that logging is our problem.

I'm not sure, since I'm not really sure what problem we're solving. It sounds like there are potentially three motivations:

I actually wasn't sure which to pick myself, since it's not as specific as most bug reports, but it seemed more like undesirable behavior of an existing feature, as opposed to a new feature. Would it be more appropriate to consider this as a feature request instead?

Can you walk me through why you consider this to be a bug report rather than a feature request?

Specifically, I got this (mail with HTML and text parts containing over-escaped HTML):

On top of this, I got some email from Pholio with odd HTML behavior, but I can't immediately reproduce it and I don't have any guesses about what's causing it so I'll assume I'm just crazy until someone else hits it.

(See also M1476.)

I've got most of a diff for this.

This is kind of time-specific since it has a version number, but I got Aphlict working on my server by navigating to phabricator/support/aphlict/server and running npm install ws@2.X (literal X) as root. This installed version 2.3.1 (im assuming the latest stable 2.X version). Upon restarting aphlict, the notifications work without raising exceptions.

See T12688#223690.

You should be able to use bin/config delete ui.footer-items --database to fix things.

(In this case, our behavior was strictly wrong, completely accidental, and trivial to fix -- but sooner or later we may make some kind of change which isn't very compatible with this older style of integration in a more fundamental way. When we do, a blog post from 2013 suggesting a set of workarounds at the time won't hold back the tides of change.)

The general story on Build/CI is this:

I think I didn't migrate this since there was no direct analog -- my memory's a little fuzzy, but I think the old query had some bugs / weird behaviors / general differences and there's no exact way to represent it after the change (and even if there was, the newer version -- with bucketing -- is probably way better for most users, so it's good to upgrade anyway). I figured it was better to just break it in an obvious way than subtly change it, which could be more confusing, I think.

There isn't enough information here to reproduce the issue as described. Do you have additional steps I can follow and see the issue locally?

I'm not allowed to close this, but it was fixed by T12757

In T12766#225295, @epriestley wrote:

Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯

Thanks! We'll keep this around and see if a migration is needed. Sounds like mostly a dashboards issue.

Can you just pick a new query and fix the panel?

Can you just pick a new query and fix the panel? My thought is if only 1 person in 12 months is affected, it's going to be faster for you to fix the panel than for us to find resources to build an old image and test migrations.