Sounds good. I'm going to close this since it doesn't seem to be moving toward becoming a bug report which we can accept upstream.

We are certainly not going to engage into paid consulting without knowing how long it might take to solve the problem, given your hourly rate :)
I would have appreciated at least a tiny hint on how to solve this ourselves instead, so I guess I'm going to dive into the code and implement a workaround somewhere. For example, tinkering with the $smart_wait calculation might be a start.

I'd be happy to work with you one-on-one to help troubleshoot issues in your environment, but we can't offer that kind of support for free. This process almost always takes up a large amount of our time and very rarely uncovers any real bugs in Phabricator or helps anyone except the single user experiencing a configuration problem. See Support Resources for more discussion of the kinds of free and paid support we offer. If you'd like to move forward with one-on-one configuration and environment support, see Consulting.

I was afraid this would happen. However, short of giving you access to our server, there is no way I can exactly describe our setup: there are fare too many variables. Perhaps we could narrow it down a bit? What could be a factor here? The obvious non-standard features of our setup are :

• linux-vserver
• 32bit userland
• LVM on soft raid
• daemon user = web user

That said, I can't understand why the same user can run hg log with negligible CPU impact, and run the same hg log through phabricator with significant performance impact. Clearly phabricator does something in addition to calling mercurial that is causing the problem, and I don't know what it could be. That's where your input would help :-)

Beyond that I don't know how you're using Calendar or what types of events you have.

I'd update Phabricator first, then see if it clears.

Actually this error started quite long ago. In my memory it started after some big changes on Calendar app. I have updated several versions before I fired this bug report. I will try to update to the latest version later. Regarding the reproduction steps, this is a background daemon log, not triggered by direct human action. I have no idea how to provide the reproduction steps. Any hint?

This does not appear to be moving forward as a valid bug report which we can accept upstream.

What branch you checkout - master or stable ?
Never mind, I found what you've done, sorry.

Wow.
With that charge you can retire at that moment ... ridiculous.
I'm pretty sure in lab clean env from scratch all will works flawlessly. The point is in working environment.
Should be some guide where to dig for a problem.
Anyway will try with new clean install and migration of real data.
And will inform my boss that my month salary some guys take it for an hour :)

Closing per lack of feedback. If you figure out how to reproduce the bug, please let us know. Mostly, this looks like someone else (admin) changed the permissions on the application.

See also T3472.

Alright, then this is it. I think a visual indication would be helpful. But apart from that, this can be closed.

I can't reproduce this, so we can't move forward. Next steps:

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

Closing for lack of feedback.

So, is it possible that the email field is shown when there is already an existing phabricator account with the same email address?

Is it test facility Master branch synced. Because there all works but here is master updated not stable.
I'm afraid that can't revert to Stable due to database changes.

So I asked a coworker to register with *his* credentials, and it turns out he can't see the email field. I strongly suspect it has to do with the fact that I already registered with the same email address when setting up the admin account initially.

Here is my ldap auth config

I tried again on a clean phabricator install (git master as of 10 minutes ago) on Ubuntu 16.04 and php7.1 from https://launchpad.net/~ondrej/+archive/ubuntu/php and still observe the same issue. So it looks like it's specific to our ldap server? Does the output I gave you above ring any bell?

Thank you for your extremely intensive efforts to reproduce my issue.

I can't reproduce this issue with the information provided. To move forward:

We also encountered this bug but after updating it disappeared.

Thanks. I was modifying php version because when it was last deployed PHP 7 wasn't supported so 5.6 was installed as well so there were two PHP versions on the server.

(I no longer need access to the server.)

Having run the scripts on a new server the only thing I can think of is the fact that the scripts change #!/usr/bin/env php to #!/usr/bin/env php5.6

@aurelijus unfortunately that wasn't it. I had local.json configured.

Chrome 56 has merged a fix for this so it should be moot in the not-too-distant future, although I'm not exactly sure what the Chrome release schedule looks like. If this only impacts ghost inlines for a few more weeks it's pretty tempting to just wait for it to resolve itself, but I may be digging around in that code soon so perhaps I'll take a more detailed look.

Is it possible that this issue effects Differential but only for inline-comments that have been ported forward from a previous diff (i.e. the ones that are rendered as slightly faded). I see this issue on this instance with this revision: https://secure.phabricator.com/D15675, none of the anchor links in the timeline work for me when I use Chrome 55, but I don't see the same issue on reviews where comments are on the most-recent diff (not faded).

I dunno, I get this error every time. I just tried it again patching back on the same repo that generated the diff:

hmm, that's pretty much it. lemme make sure i'm not missing anything

Oh and libphutil is at c5848b71c10 and arcanist is at ade25facf

I am also at HEAD and cannot reproduce that error. What steps am I missing?

1. Create a diffusion review with arc diff
   1. Run arc patch <ID of review>

59s is ridiculous. :(

I think @jboning was working on moving Phabricator to new hardware last year, but I don't know where that ended up. Once that happens, we can get you clustered for performance.

You're right, works fine for me against a Phacility test instance. Huh.

And also T7664.

This sounds like T8588 offhand, unless you can reproduce against Phacility hardware.

First thing to check is if your DB configs are in /conf/local/local.json, I went through the same issue, because my mysql configs where in /conf/custom/myconfig.php and for some reason newer versions of phabricator do not evaluate PHABRICATOR_ENV properly. So basically run

I can't reproduce this either. Here's:

Alright. If we don't hear back from you in a few days we'll close this since we can't move forward on it, but you're free to file a new task when you're ready to move forward.

I'm using a VPS but don't have the facility to easily clone it as is and can't risk it being broken anymore than is now. I will get a small instance setup which reproduces the problem (using ansible to roll out so should be straightforward), that probably won't be until in the week, right now I'm working around it by mirroring and pushing to another remote temporarily.

I have restarted httpd. I try to disable some chrome extension. Now it works.

I also can't reproduce this locally or on a Phacility test instance.

The Phacility cluster is on 2017 Week 1 now and I can't reproduce this there, either:

I wasn't able to reproduce this earlier so I'm not sure how to move forward, but feel free to follow up if you have more information.

Cool, glad things are back in working order. Thanks for following up.

This can be closed as invalid (or resolved I guess). Looks like we performed an install and some upgrades at an awkward time when some storage upgrade changes were occurring. We've run several stable branch updates on the install since and it's been fine.

We still require steps to reproduce and version information on bug reports. See Contributing Bug Reports for more details.

We haven't received more information about this in about a week and can't reproduce it, so we can't move forward. I'm going to close this until we get new information.

Yes, this is consistent with running bin/storage upgrade from master, then switching to stable.

Offhand, It seems your database is on master, and code is on stable.

Can you show us the output of these commands?

metamta.email-body-limit is unset.

Also, is metamta.email-body-limit set to something crazy? I think that only means main-body (not body + attachments) right now, but it should probably mean body + attachments + headers.

Oh, never mind, that's the Differential patch responding to the commit, so metamta.diffusion.byte-limit isn't relevant.

Thanks, I'll take a more in-depth look at this.

I've been also playing with the shellcheck linter and evaluating it using the following .arclint entry:

Aha -- the diff as posted for review was mostly-reasonably sized. The diff as committed was the huge one:

mysql> select differential_diff.id as diff_id, creationMethod, SUM(addLines), SUM(delLines)
    ->   from differential_changeset
    ->   join differential_diff on differential_changeset.diffID = differential_diff.id
    ->  where differential_diff.revisionID = 253041
    ->  group by differential_diff.id;
+---------+----------------+---------------+---------------+
| diff_id | creationMethod | SUM(addLines) | SUM(delLines) |
+---------+----------------+---------------+---------------+
|  837437 | arc            |         11845 |          8567 |
|  837558 | commit         |       1752986 |        396108 |
+---------+----------------+---------------+---------------+

bin/worker execute --id 35362582 did not work because the task was archived. Instead I ran ./bin/phd stop; ./bin/worker retry --id 35362582; ./bin/phd debug PhabricatorTaskmasterDaemon. The key seems to be the production of the .patch file itself, not the number of files. Somehow these users managed to cram a >100M patchfile into Differential:

Alright, I'm actually having trouble reproducing this. Here's what I tried:

The API is considered unstable and there seems to be work to do about this manual transformation from arc lint --output json (which isn't even JSON) to harbormaster message JSON format.

There may be some merit to changing the UI to say "Title" or "Error Title" instead of "Message", but this is so low in terms of value ("Admins that don't read docs confuse fields") that I doubt this will actually happen.
Changing the API is even less likely, because that will actually break other people's code.

Partially it is. I remember now, I've fallen in this trap the second time now, I forgot what name is (again, btw). I told you that name is too generic. The first time I found out that Message is a wrong title for Linter rule name and worked around it. This time I forgot it again, because the terminology is not consistent.

OK, looks like this is just a case of miss-reading the docs:

• name (optional) Text summarizing the lint message. For example, "Syntax Error".

name in the regex does not mean "Name of linter" but "Title of error".

It's my own script. I haven't found anything like this in the sources. I also haven't found any hints how to integrate`arc lint` without pain (no --target option like for arc unit).

What made the translation from the string-after-regex to the harbormaster json structure in your example?

I've just noticed that arc lint --everything output summary gives me this:

I'll try to give an example which makes clear that linter message is not meant to be linter name.

This issue was solved by updating to the latest everything. I apologize for the noise. :-(

Here's the same rule with test console:
https://secure.phabricator.com/herald/transcript/185171/

(We don't maintain two code paths for Herald / Test Console)

Please complete the bug report first.

The transcript you are pointing doesn't seem to be obtained using Test Console. Can you try using that?

That's correct. I'm not sure what's going wrong. My guesses are the crazy stuff you might expect like: