I'll add a link too, it's reasonable.

The problem here is the default for the default branch, when the user didn't set it explicitly. In a user perspective it's then hard to know there's this option at all. Some link to set the default branch from the error could be more clear, but I don't think that's a common in phab to do that.

I don't know, I'm confused today. I'll see if I can make this cleaner at least. Somehow. We depend a lot on having a default branch though, like picking commit crumbs.

I will ship my branch selector dropdown and make sure it works without a good default branch.

That is, my expectation when you have set "Default Branch" to "mmmmmmmmmmmmm" and visit the repository page is just:

This is what it did in March 2016: T3607#163684

Like, it's not a regression from the Diffusion re-work.

Am I right there?

I think the part that is tripping me up is this never worked, that is, if we had a bad default branch, basically that's all we rendered. We didn't also render a list of good branches.

I'm attempting fixing this right / long-term. I think I'm ok right now.

Where is the exception coming from?

Before we didn't render the table, so the link to visit said table as full screen, doesn't exist. I think I need... better fallback here.

The reason I took navigation away is we throw exceptions instead of error messages when master isn't present (or have no commits yet). Do you remember the reasoning there (using Exception)?

ok thanks for the nice and easy repo steps. I'll have something after lunch, got appt at 11

I believe the issue here is:

oic k thx

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

In the refcursor table, our current autoincrement is at 312,036,016. This is only 7% of the way to int unsigned, but the fact that we've made it to 7% in 18 months might suggest that column should be BIGINT, unless there are performance impacts of that.

See PHI11. This has material impact when using PhabricatorRepositoryRefCursorQuery to query landing targets, and likely impacts the logic in DifferentialRevisionOperationController.

We've been experiencing this problem from time to time as well.
In our case between two Phabricator installations.
The internal one observing a repository from a central dev server which always works fine.
Then the internal phabricator has a "mirror" URI configured for the repository to push any changes to an external phabricator installation.
This mirroring fails from time to time with the same error others have posted before (Unable to identify the reftype of 'refs/remotes/... in src/applications/diffusion/engine/DiffusionCommitHookEngine.php:404). Sometimes i could fix it by simply deleting a remote branch that was no longer needed anyway.
I've added a dirty fix now by inserting a "continue;" at line 404 so that the parser in findGitRefUpdates() simply skips unknown ref types and still imports the changes instead of failing completely with an exception.
Though i'm not sure what kind of side effects i might have introduced with this.

This is pretty sad that this bug is still open. I haven't found a way to use Phabricator with recent Mercurial, so I'm sticking on 4.0.1 ATM.

Since the History is now dumbed down and separated from the Technical details on the Graph view, it might be more useful to filter out merge commits from the History view. Perhaps they can be replaced by a small "Merged to <branch>" link at the bottom of the box for the last non-merge commit that was part of the merge.

In T12896#228825, @jmeador wrote:

We"solved" the problem with a small python daemon that pings repository_statusmessage.epoch every minute and calculates the delta. When these deltas surpass Phabricator's max delta (21,600 sec) we page the oncall. For repositories that are mission critical, we use a smaller value. It obviously isn't a perfect solution, but it gets the job done and it's been extremely stable.

A customer is hitting an issue where pushes to staging areas do not push LFS objects. I'd guess this is an LFS upstream problem based on a hazy recollection of events here.

Solves things for my instances, cheers!

Going to keep this Open and build out some proper blank states. This feel pretty janky.

I pushed a hotfix up at HEAD of master, let us know if you're still having problems. Thanks for the report!

This information may be entirely useless, but it is somewhat related. We have a large number of repositories, with multiple clusters so this affects us in a major way.

From elsewhere:

Also related: T12417: Show failing status of Diffusion repositories in top main menu bar.

Synchronously in the request. I'll look at adding logging.

If you go through the process manually with the web UI, are the versions OK after initial creation? After adding an observed URI?

So I'm not immediately able to reproduce this. Some possible questions:

I used this parameter bundle to create a repository:

I'm attempting to reproduce this from the web UI first. I created a new repository, and get 0 versions as expected:

This should now be fixed in HEAD of master and promote to stable later today (within about 12 hours). This change hasn't been deployed to secure.phabricator.com yet but will be deployed no later that tomorrow morning (about 24 hours from now), at which point the example link you provided should start working.

We use (most of) the graph code for drawing the "Task Graph" and the "Revision Graph" so we need to keep it around in the upstream anyway.

doh! nice. I obviously need more coffee.

("Graph" button in upper right.)

https://secure.phabricator.com/source/phabricator/history/master/

I know just maintaining the hooks is more work but certainly less than what's involved in maintaining the graph code.

I think that's what D18131 did -- or do you mean something else?

Maybe provide some extension hook-points in diffusion so that the community can maintain the commit graph visualization as an extension?

See also T10005 (bulk editors for all applications) and T6722.

I think a minimal reproduction case which is typical of this example is:

Looks to be just the presence of the "?" in the text

"XXX://123456 XXX XXX XXX://123456 XXX XXX"

You and me both. I am super confused.

Well the stack trace says PhabricatorYoutubeRemarkupRule, so I'm confused what the issue is.

LOL @chad Literally reproduced this issue here by trying to paste the above line without the back ticks. It refuses to let me comment.

I'm not sure how without giving you the entire commit message which I cannot. I think key would be a having a commit with a line (probably the first one) that looks like this "XXX://123456 XXX XXX XXX? XXX://123456 XXX XXX XXX"

How can we reproduce this issue locally?

There also seems like there may be an issue with the current parsing logic since the "detected URI" has spaces which I do not think are valid in a uri and it should have been detected as two separate URI's with some stuff in the middle.

The URI that is ambiguous is a URI to a company App on MacOS. The only part of the URI that matters is the xxx://123456. The rest is just the title of the item referenced by this URI and this title contains a "?" which mixed with T12526 may be causing this issue. There may also be a place you now need to catch exceptions thanks to URI parsing logic changes. Just guessing here from what I can tell in the code.

I think we should have our crontabs in version control regardless of whether or not we add tmpreaper to them, so I'll make a task for that.

If you want to move forward with that:

This should do the trick. It runs off atime by default. We could just set the time period to several days if we wanted to. Alternatively, if the filenames for extremely long-running jobs are predictable, there's a --protect '<shell_pattern>' argument we could use to avoid cleaning up those files.

Every repo host is equally affected, so I'd like to deploy crontabs as part of the regular deployment process if we use them as part of the approach here. That would require first codifying a handful of custom crontabs, including one on secure which regenerates documentation daily on only one host. This codification should happen anyway eventually, but it's a little bit of work, and wasted effort if we're switching to Chef/Salt/Ansible/etc soon anyway.

Should we just add a crontab entry to clean /tmp to paper this over until we get it fixed for real?

Ouch, sorry for the noise. I usually get confused between Diffusion and Differential.
Keep up the good work.

Here's another clue, from the relevant host's error log:

This task is for Diffusion feedback, not Audit or Differential

My two cents here: