@epriestley I was trying to recreate my problem I had a month ago and write a task (bug report) for it and wasn't able to reproduce the issue of Drydock trying to allocate resources indefinitely. Have you already added a timeout to Drydock leases?

Any estimation how long can this be fixed? If it takes long, I will break the parent/subproject relationship. Otherwise I can just wait for the fix.

If you have the ability to edit a diff, you have the ability to edit a diff and it's relationships. That seems the simplest, most straightforward way to describe the way permissions work here.

I expect, that I can a) don't add commits etc, no matter, if I press the button at the task nor at the commit for example, or b) I can do it at both ways.

What behavior do you expect?

@epriestley Why? Actually I think this is confusing.

This is working as intended.

Did you run into this on a local install or this install?

Thanks :).

In T11364#186934, @epriestley wrote:

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

@epriestley Because it allows the reader of this report to reproduce the underlying issue without cloning anything or clobbering their .arcrc. Here are some less contrived scenarios, which are not mutually exclusive:

• the user makes a typo (project lacking .arcconfig, or trying to use Phabricator for the first time themselves)
• the .arcconfig comes from a time before Let's Encrypt (e.g. if you're in the middle of a git bisect that takes you back some distance)
• the admin is just attempting to migrate people to more secure services and does not expect that services will fail (or at least not fail in such an opaque and confusing manner) in the face of a redirect

This looks closer to a server configuration issue to me and is actually a pretty strange behavior (mostly because i'm not sure how the redirect after it looks like a request is served works). If I go to http://secure.phabricator.com/api/user.whoami in the browser i get the following

{
result: null,
error_code: "ERR-CONDUIT-CORE",
error_info: "You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies. This was a Web request. This request had no CSRF token."
}

as expected or maybe not? However if i run curl http://secure.phabricator.com/api/user.whoami i get

{"result":null,"error_code":"ERR-INVALID-SESSION","error_info":"Session key is not present."}

Why are you running arc install-certificate with a manually entered URL?

I guess you're right. We've never really questioned the behaviour of these GUI tools. We assumed that because they do this automatically and provide no way to disable it "they'll probably know what they're doing".

(We could detect this case and fail with an error, but the root issue here seems to be that tracking is being set on a remote branch which the local branch really does not track.)

Generally, I'm very hesitant to use "will the push change anything" as a signal, because I think this is unintuitive and will create confusing false negatives. Specifically, if you do this:

Have you asked Sourcetree or Git Tower to change their behavior instead? They can compute ahead/behind without setting tracking, and it seems like setting tracking is not really correct here (the local branches do not really "track" temporary remote CI branches in the traditional sense).

I'm not sure actually. Most of us use GUI tools like Sourcetree or Git Tower, which automatically set up tracking when a branch is pushed. I guess they do this to be able to show the "Commits behind / ahead" badges on branches.

Why does the local branch track the remote branch? Do you push using --set-upstream? If so, why?

Looks like that'll work nicely!

Thanks for the report, and for the good reproduction instructions. D16313 should raise a better exception.

That explains it then; I'm not used to being complimented about my eyesight :P

Clearly we should have a Services starting with "CloudF..." header.

I'm using CloudFront. That explains why I ignored the note, though; it
doesn't apply to me!

@jonah214 said he's using CloudFront (AWS) while that note is about CloudFlare (an unrelated product/company with a nearly identical name) so I'm suspicious there may be more to this than meets the eye (or maybe CloudFront was a typo).

I think we owe @avivey another lunch at this pace. Such eyesight!

I added you to Community, so you should have sweeping janitorial powers now.

I must have missed what @avivey pointed out. Thanks! Sorry to bother you guys.

Did you see the note in https://secure.phabricator.com/book/phabricator/article/configuring_file_domain/#approach-cloudflare ?

I can't reproduce this. Here's what I did:

I'm curious, is there any other way to trigger Herald to process a Differential review *other* than uploading a new diff?

no.. they've been a part of that project since the beginning

If you're not allowed to see PHID-PROJ-rwnekrajar5m6diprobx, it will not be returned from project.query. Herald should be seeing all projects though, so PHID-PROJ-quo7cpreceuh6hnor3pw missing is strange.

yes... they're secret :)

Is there anything special about the projects PHID-PROJ-rwnekrajar5m6diprobx and PHID-PROJ-quo7cpreceuh6hnor3pw? Is any of them secret?

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

This doesn't appear to be a valid bug report. You must update Phabricator before filing a bug report (your logs indicate you are a month behind), and you must provide steps we can reproduce the bug.

Though I don't completely understand the specifics, I do have this issue resolved.

#1146: Table 'phabricator_metamta.metamta_mailinglist' doesn't exist

is an error from MySQL, and not from Phabricator. I believe the problem started when I restored the database from a backup. Rather that using a dump/restore, I rolled back to a previous filesystem snapshot on my database server. That filesystem snapshot contained :

mysql/phabricator_metamta/metamta_mailinglist.frm	
mysql/phabricator_metamta/metamta_mailinglist.ibd

database files. That particular table, however, no longer exists in the current versions of Phabricator. Once I removed those two files from the database server and restarted the MySQL server, the bin/storage upgrade command worked without error.

Awesome, thanks @epriestley. The update cron script runs that bin/storage upgrade every time.

Note that you need to bin/storage upgrade after picking up D16312 for this change to take effect. You should normally be doing this anyway, just mentioning it since it's not obvious that this would require database adjustments.

I think arc actually calls differential.getcommitmessage and then passes the result right back to differential.parsecommitmessage to split it into fields. That could/should work differently than it does.

Where did the phid get to the user anyway? If it's arc diff --update, it shouldn't try to parse the comment, and if it's arc diff --create, it shouldn't have any tags?

We can have this render "Tags: PHID-PROJ-abcdef" instead, which is an "improvement".

No this is just a general bug report since it's a fairly confusing error message for end users.

Are you looking for alternative ways to block commits, or is this a bug report about "arc diff fails when revision has secret project tags?"

T8200 describes a somewhat-similar issue.

In general we want people to update if possible before filing a bug report. The reason is most real "bugs" are fixed usually same day reported. For example we had a recent "Repository is not attached" exception that was fixed same day, but we're still getting reports trickling in weeks later. Being on this week's stable is all we usually expect. HEAD of master is better, but not required.

First I apologise if I somehow came across with any hostility, that was certainly not my intent.

@ofbeaton How can we make the bug reporting guide more clear with respect that we don't take bug reports on older versions of Phabricator? Nor do we take feature requests or feedback as bug reports.

Thank you for the timely response. I'm glad to hear you're thinking about this. I still have many concerns about this that I hope you will consider.

This appears to be a problem unique to your environment, because we and many other users follow the upgrade steps routinely without encountering this or similar errors. In particular, I can't reproduce it given the information provided.

Not only that but the language has moved away from human-friendly terms like "hosted" vs "non-hosted" to "observe".