@avivey - I have added the Steps to reproduce the issue.

Have you fully read Contributing Bug Reports? This ticket is missing most of what is required for a handling, primarily reproduction steps, as highlighted there.

Actually, this is probably not T10968, although perhaps it's something similar -- possibly bad behavior when generating inline diffs or diff attachments for mail? It should normally be very difficult for a TransactionPublishWorker to generate mail side effects multiple times.

I've now tried on MySQL 5.6.27 instead of MariaDB. The same thing - cannot create a project. This time the process results in 504 Gateway Time-out. I guess if I'm the only person reporting this issue, the problem might lie with my setup. What's puzzling my is that it's only with the projects. 60sec should be enough for the FPM to process this request, I guess. Thanks for looking into it.

Sorry for this mostly stream of conscious while I was debugging the issue. The main way to resolve this that I found was find the DREV that is being processed in the workers table and kill it. I think some underlying issue exists in how this is being processed but until I have more time to look into it I am happy with just running ./bin/worker kill --id 123

Reproductions steps :

It's also vaguely desirable if the bulk processes (deploy/upgrade) can explicitly prefill the disk caches after mass-purging, since a bulk prefill is significantly more efficient than doing a readthrough fill moments later when the daemons restart. This only smooths out API burstiness during deploys, though.

Sorry, we don't offer help diagnosing problems. See Support Resources for a list of what we do and do not offer help with.

Some other things that could use updates:

After more thinking, I'm leaning heavily toward just doing a "display rename":

I used the new support code in connection with a manual instance rename (see T11413) and it appears to have worked.

Oh, Complete!

root@ip:/var/www/issues# cd phabricator/
root@ip:/var/www/issues/phabricator# git pull origin master
From https://github.com/phacility/phabricator

• branch master -> FETCH_HEAD

Already up-to-date.
root@ip:/var/www/issues/phabricator# cd ../libphutil/
root@ip:/var/www/issues/libphutil# git pull origin master
From https://github.com/phacility/libphutil

• branch master -> FETCH_HEAD

Already up-to-date.
root@ip:/var/www/issues/libphutil# cd ../arcanist/
root@ip:/var/www/issues/arcanist# git pull origin master
From https://github.com/phacility/arcanist

• branch master -> FETCH_HEAD

Already up-to-date.

You shouldn't need to edit code, just update Phabricator. https://secure.phabricator.com/book/phabricator/article/upgrading/

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

I using git master. and i did edit code to https://secure.phabricator.com/diffusion/P/browse/master/src/applications/config/controller/PhabricatorConfigListController.php;f379858874a3336dc36cc8b7e77b0d0b698b2fff$54 and error not complete.

After D16427, I have an automated version of this working locally. It needs some more UI polish and I'm not going to try to get it in this week, but the support code (services dump / services export) will go out and then this can maybe go out next week or so.

Would this apply to having ability to set an edit/create task template as default for a workboard/project? This recently came up in discussion the other day where someone wanted tasks made for a workboard/project auto-inherited permissions. My mind turned to making a new Create task template with the permissions they wanted, but it didn't seem there was a way to set it default to a project. It sounds like this task touches on similar area?

Going to assume you are not up to date.

What version of Phabricator are you using? This should have already been resolved at HEAD of master.

Yes, this seems to be exactly what the other issue was referring to. We've just recently upgraded (previous codebase was 2+ years old) and massive amounts of commit email are getting sent out.

Yeah, this is likely the same as T11188. See that task for some additional discussion.

Well, I'm guessing overall, roughy my theory is:

This is expected, as they are most likely not previously discovered commits.

I also don't know how to reproduce the problem. I followed the guide found in T10246 to set up DryDock. I reported the bug hoping you could help me diagnosis the problem. How do you limit the number of working copies ?

This should now be fixed in HEAD of master. Thanks for the report!

This should be resolved at HEAD of master. Thanks for the report and the detailed analysis of the issue.

D15133 (making array utility functions accept any array-like object) is a possible attack on this in the general case, but I'm just going to fix this narrowly for now since it hasn't been a frequent/common/recurring problem so far. A more general approach may be warranted in the longer run.

I can't reproduce this.

Got it, sorry I missed that! Thanks for all the help you've been able to provide otherwise. If I figure out the root cause for this issue, I'll let you know. Thanks again!

Yeah, I'm thinking maybe just a button/link somewhere that takes you to a page similar to this one listing "Refs":

Sorry! How could we rewrite Support Resources or Contributing Bug Reports to be more clear that we don't offer help diagnosing or troubleshooting issues like this?

Not sure that you read my response. I wasn't asking for installation help. Please re-read.

The fatals should be fixed in HEAD of master. I'm going to retarget this task to clean up the actual method calls, but this should have no user-facing impact.

@PhoneixS, thanks for the hint, that workaround worked for us for the time being.

D16420 restores setIcon() as an alias of setStatusIcon() as a quick fix for the immediate issue, since I found at least two other affected interfaces (Drydock, Almanac) and am not confident there aren't more.

This was likely broken by D16418. I think setStatusIcon() provides equivalent functionality, let me take a look.

Yes, this is intended behavior. See T10262 for discussion. See T10262#158198 for comparison to other systems, many of which use the same approach to access control for the same reasons.

Same issue here

This is intentional (and not a security issue), the URI contains a security token valid for 30 days (or until the policy is changed).

Sorry, I was responding primarily to @chad there -- the preview is at the bottom. I've circled what I was talking about here:

(I believe we already show any changes that pressing the submit button will make to subscribers accurately in the preview. This wasn't always true prior to EditEngine and I think the preview/actual effect would sometimes disagree in weird cases, but I believe the preview is now always fully accurate. However, it's quite easy to miss.)

This isn't a valid bug report, and we haven't received new information in several days.

Sorry, we don't offer installation and setup help. See Support Resources for help understanding what kind of support is and isn't available from the upstream.