No cloudflare or caching.
Did restart the server after upgrade.
Issue began to happen following upgrade + restart on Saturday 30th January.

This generally points to something environmental on your install. Did you restart the webserver / apache after upgrading? Any proxies or other resource caching going on like cloudflare?

Can't reproduce on this install, though.

Ok, checking Firefox's error console and I get
Error: JX.initBehavior(map): behavior(s) not registered: dashboard-query-panel-select
Expanded to reveal:

JX.$E()                                              core.pkg.js:2
JX.initBehaviors()                                   core.pkg.js:178
.members._handleResponse/when_complete<()            core.pkg.js:235
.statics._complete()                                 core.pkg.js:193
.statics._loadJS/load_callback()                     core.pkg.js:184

Yeah, it feels a bit like the "baby's first typeahead" button to me (since it didn't exist for so long, and is usually useless if you know what you're going to select) and it usually takes me a minute to remember it's there.

FWIW I don't think I had clicked on since first testing out typeahead and had come to associate it with "this is a magic typeahead box" not "click for more options".

Here's a workaround:

I can't repro on any of these steps. Can you give us more specific details maybe that we're missing. Sounds like Javascript didn't fire or something for you. Can you reproduce on this install?

phabricator a45fe337a12f29efdf425086018f1160906f0d0f (Sun, Feb 7)
arcanist 57f6fb59d73994d90cd94143787424ce0fdbf73b (Mon, Jan 25)
phutil f43291e99d36045bc459e5133454c0d8fd8768ea (Thu, Jan 21)

In T10296#157683, @chad wrote:

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

I installed compiled and installed git from sources on the server, v2.7.1 and that did not solve the problem:

These are still prototypes for now, you should have seen this when you created the Milestone:

Some day we'll provide some kind of tooling or migration approach here, but this seems stable for now.

Thanks for catching this!

That fits what the code does - it looks like it gathers all good options, and that includes a "some" projects, if any.

Turns out that it's not just if zero projects exist, but if the user attempting to create a project does not belong to any project themselves. i.e. no projects are shown.

Looks like it was broken at e1c934ab22d8c0d88ec1ce0d73bc497e563b4acb (Works at 8a9f7609755af5e32c2c287c4b732d213cb680ee).

• @avivey we have our own library that is loaded in when arc runs. I had an out of date version of our library which caused this to throw an error.
• The chief complaint is that arc unit for unsound tests exits with a status of one since it's indistinguishable from arc completely failing.
• A harbormaster build step is reading the exit status to determine if the test was a real failure or just the result of an unsound test not passing.

I don't fully understand the issue description:

Looks great, thanks for the quick turn-around!

Hows this:

The behavior is not inconsistent with the documentation, and the documentation does not suggest the configuration you selected.

I was referring to T9973

In T10274#157022, @epriestley wrote:

Where's the other request for this?

I was referring to T9973

The motivation was this scenario:

You can land onto a remote branch with a local copy of the branch which isn't really that branch but is just some other branch which you've named the same thing as the other branch.

We can't do that if we actually write onto Release1. The original task or tasks are linked from T9657. The new behavior generally remedies a large range of scenarios where users were confused by arc land writing to Release1 when they did not expect it to.

I think that makes sense for arc land, and as odd a workflow as I find it, I understand the need to support it, but arc land --hold implies modification of local repository, no? Previously arc land --hold was a legitimate workflow that put the user's repository in a very predictable and easy to understand state. Now the end result feels like some process got interrupted in the middle and is really not useful for anything other than pushing. It even kind of looks like a repository that is left in the middle of a failed rebase, with detached heads and unmerged branches. It also leaves garbage branches behind that the user now needs to go clean up manually, and since the branches do not appear merged into trunk, it needs to be a force delete, which is always a little bit of a scary operation, especially for people not experienced with git.
>

See also T8227.

I'm very much with you on that one. That's why I'm suggesting assuming a certain intent behind using arc land --hold and Doing The Right Thing(TM).

You can use arc alias to define a new command which runs arc land --hold --onto X && git branch -f X HEAD or similar.

Yeah, but that requires us to specify the branch to land onto, which is something arc already knows from .arcconfig.

T7477 is tracking this, it's reasonable to support, but not very common overall.

External.

Is the mailing list a Phabricator mailing list or external?

Because I wasn't replying directly to the task email, I was replying to a colleague's response in the thread. I did not change any recipients from the default when hitting reply all. The sequence of emails went like this:

Why did you CC the task instead of leaving it in the TO field?

Isn't this a duplicate of T8982 (and of T7097 by extension)? The fix you propose has already been submitted, though it was later abandonned (see D13745).

Where's the other request for this?

Yes, that will work.

In your first example, you can likely:

thanks

T9657 is probably the relevant guidance. There is no way to get the old behavior back.

and you beat me to it.

Sorry, I accidentally submitted in the middle of typing :)

This is not a valid Phabricator bug report. Please see Contributing Bug Reports.

It ok no feel bad

Thanks for the report @perezd and sorry for my bad testing!

I feel dumb because in my testing I set the field to literal null and not null.

and also the culprit! hoo hoo hoo!!

@epriestley is the hero.

mine looks identical to yours (app settings)

PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:34:46)
Ubuntu LTS

(also maybe helpful, what PHP/OS you are running)

/applications/view/PhabricatorFilesApplication/

Can you look and see what your limit is set to?

These files were well under 1MB FWIW.

b51a859636ac was recent, so maybe it did break something.

It's anything over 1MB.

I haven't tried to reproduce this, but the error about "store large files" seems out-of-place if the files are small.

I had never setup anything for file storage in the past. It was never configured.
I've restarted php/apache many times, including immediately after I updated it as the documentation states to do.

If you just updated Phabricator, how long has it been and did you restart PHP/Apache?

set that field to null, and you can repro it.

set that field to null, and you can repro it. I did not get this error prior, and I should not be getting an "upload" error as I try to simply view a source file in my git repo via diffusion.

https://secure.phabricator.com/book/phabricator/article/configuring_file_storage/ explains file storage in Phabricator.

Maybe I'm missing something obvious, You say if you set the local-disk path the error goes away. So what is the bug you are reporting, specifically, and how can we reproduce it.

Yes?