1. It's not configured
2. Yes
3. I'm not sure, these are my install versions (stable branch) :
   • phabricator f75b1cf562c0c3646324864851d693ef1069a068 (Mon, Apr 18)
   • arcanist 01b6fe8bb0239a4bce03f58d6288a3a52ad83a91 (Sat, Apr 16)
   • phutil b8c65df2a910a7028d39bec602d181428b6ce01f (Sat, Apr 16)

(edit, it has rP37b93f4)

• Is security.alternate-file-domain configured on your install?
• When you say "redirect to the correct file", do you mean you get taken to the file detail page /F1234?
• Also, do you have rP37b93f4 locally (April 7)? (You can grab the hashes in Config → Versions if you aren't immediately sure and I can figure it out from there.)

Ah, is the auth token (first [shortened]) same for every user? It is in my case

1. If I visit the URI while being logged in to the app, the browser redirects to the correct file, the download link works
2. The download URI is the same as the logged URI
3. Visiting the URI with private window returns normal 404 page

You shouldn't need to configure diffusion.allow-http-auth -- the auth token is basically the first [shortened] in the URI, so that appears to be working properly.

I think we generate this warning long before attaching the diff to a revision, so it isn't trivial to know where to look for a "you already confirmed this prompt once for the current revision" flag.

I'm using S3 as Files storage backend, phabricator runs behind nginx, and the diffusion is hosted over SSH (diffusion.allow-http-auth=false, HTTP is not configured anyway). I'm having an issue:

• pushing and pulling small files (<2MB) tracked as LFS -> works flawlessly
• pushing 11x 1 GB files works, but can't do git clone / git lfs fetch (got the same issue as @benjumanji, the lfs_trace log is similar, 404 errors when getting the lfs-* files)
• pushing a 11GB file, doesn't work. forgot the error message, will add it later if needed

please close this. i think not restarting phd is my fault.

reproduced it on a fresh vm.

Very Useful!

@fcoelho - Would you be able to test your log change with pushing to a mercurial repository not hosted by Phabricator, to compare with the log from your previous comment?

We appear to be stable here now:

This is also maybe a good time to fix all the bad old mysql vs mysqli stuff, mostly:

I can't reproduce this. For example, this host does not reproduce the issue:

D15781 is promising and it looks like we can do this purely on the client if it has relatively old PHP, without requiring relatively new MySQL and special configuration on the server.

Also, the workaround now is to do a search so it's not horribly broken, it's just not as great/fast/efficient for us as it used to be.

@chad yeah it's been a very long time, a year sounds plausible. I keep meaning to share this with you guys but I had been putting it off for a very long time as it hasn't been as important as other items in my world. One of the challenges with these sorts of things is that even though people in the field may be hitting the issue, they're usually trying to do something and in their workflow and don't bother sharing it... it was only when I asked around that people were like, "yeah, I miss how it used to be a long time ago..." etc.

Yeah, looks like Tasks were removed from ProjectProfileController in January of 2015. rP3bc54c204

I honestly can't even find where tasks was the default on project home... How old was your instance? I checked back 1 year and it was a side-nav icon then, so it's been over a year since we moved tasks off the project home page.

It isn't a common use case, actually. If it were we'd be very aware of it given the significant length of time it's already been at HEAD.

Mixed progress. Repository clustering has been stable in production since the last update, and appears to actually work, which is good. We've hit a few minor snags (like a missing sync-before-read in diffusion.querycommits) but all pretty much expected stuff and nothing troubling.

@chad I see - my gut is that this is a common use case and that most teams will not take the time/energy to do this customization (or realize it's possible) but that they'd value having an easy way to see tasks as the primary use case of clicking a project name. Just my 2 cents.

Sorry to hear that @otto.bretz, but glad you're still happy with the service overall. I think this is the longest unplanned downtime we've had since launch and it's definitely not acceptable to us.

We'd prefer a customizable solution vs a hard wired one, if that's what you mean, as that benefits the most scenarios.

@chad thanks - so sounds like you don't think this would be beneficial to everyone to have?

Like just don't show it at all? That seems reasonable to me, although 0.00000000001 is very funny and we would be losing a truly great joke at such a young age.

maybe herald adding a subscriber is truly 0 then as a feed story.

T10308#158036 has a custom panel you can add to your install to shortcut and make adding this locally to projects easier.

Long term you can expect Projects will pick up features from Dashboards. We'll let you customize the nav, customize the page, and customize the landing page. You will be able to recreate the old experience if you so choose.

I appreciate that we can customize this, however this solution is not feasible for us as we have dozens of projects and add new ones regularly.

That's because it was deliberate self-subscribe which is so completely boring that we normally wouldn't even show it. I think it's arguably correct to show the Herald story? Maybe?

This is an emergency.

Deliberate Subscriber + Herald Subscriber = Herald Subscriber Story.

See T10308#158014 for specific instructions.

You can customize your navigation to point to open tasks on any Project. For now, you just have to manually add each link to each project.

Though this downtime came at an unfortunate time for us (we just migrated from bitbucket and in the middle of the workday here in Sweden) I must say that you have dealt with it in a phrofessional way. Thanks.

Thanks, I think that should be fixed now. Not clear if it was related to everything else and I can't immediately come up with a way that it would have been -- I'll keep an eye on it. We've made some changes to the Aphlict server recently and it might have some issues that still need to be worked out, so it could be purely coincidental.

so would you mind closing the task? I can't do it myself.

I have no idea if we plan to add it or not. See Planning for how we prioritize time.

Not sure if its related but I get a message regarding "unresolved setup issue" on our instance[1] now:

If you don't plan to add it: just reject the task - no problem. I just wanted to let you guys no that there is a slightly more secure way of doing what you provide to all the novice users out there.

The diffusion.querycommits method needs to sync-before-read (at least, if bypassCache is provided?) but currently does not. This can lead to tasks failing on the daemon on an un-synchronized node. Things self-heal, but it would be nice to prevent this.

Some additional response steps:

i'm offsite until next thursday. will update the latest version then and recheck. the version used is about 2 weeks old and from stable branch.

It should use the base-uri; However, the early-return in that function makes sense, in the case of an absolute URI.

Accepting contributions isn't free to us. We bear the cost of testing, accepting, documenting, and providing lifetime support. See https://secure.phabricator.com/book/phabcontrib/article/contributing_code/ for more details.

From here on, this analysis discusses some private instance data. I'm generally very hesitant to disclose information like this, but the data is non-identifying and the nature of the data is important to understanding the nature of the failure, so I think disclosure is reasonable in this case. I've limited the disclosure to only include information important in understanding the technical aspects of the issue.

this still applies 2 years after sending a diff. is there missing something?