I will use a completely clean build tonight and reproduce this but the code hasn't changed since 2015.

Offhand, these don't look like current / valid versions of Phabricator. They are out of date and installed from somewhere other than our source. Please see Contributing Bug Reports for what we require in a bug report.

I can't reproduce this. It's possible that you actually experienced T11165 and misremembered exactly what you'd done, or performed one edit in a tab with the other tab open.

This is by design, and explained in the documentation.

Good catch ! This is a disturbing behavior for the end user though.

This is documented in the userguide.

Weirdly, another server restart fixed this for me.

Awesome guys. I can confirm that this resolved the issue.

I think you can unlock yourself using the cli

I deployed this to the Phacility production cluster.

I'm going to merge this into T12142 since that one has an earlier timestamp even though this one is more pure of heart.

In T12143#208308, @chad wrote:

This is fixed on master and stable but hasn't rolled out to Phacility yet.

For the record, this is like the best, clearest bug report I've seen in months. :D

Are you filing this as a Phacility customer?

This is fixed on master and stable but hasn't rolled out to Phacility yet.

Ok I cherry-picked it, way easier than I expected.

I pushed this out to master and @epriestley will probably cherry-pick it to stable today.

Bisects back to D17235

Confirmed, we'll have a fix here shortly and probably cherry-pick to stable.

I can repro on an instance upgraded at 20d1bb8fdf too. And indeed PhabricatorProjectWorkboardProfileMenuItem or PhabricatorProfileMenuItem classes don't contain a validateTransactions method.

If this is a bug report, please see Contributing Bug Reports and fill out all required information. If this is a feature request, please see Contributing Feature Requests. If you need support for your account here on secure, please just use General Chat or contact@phacility.com.

I'll make sure to update this task with full reproduction steps on Monday.

I appreciate the details and pointers - we may look at a custom reject transaction and/or required action bucket. I just went digging here for related discussion to see if others may have run across similar scenarios.

If you miss a comment and then forget about a revision you authored for a while, it probably wasn't that critical?

I can investigate further what issues people are having with the current solutions - I'm not sure being critical is the concern but more-so there being a delay for the change to land/verify without it being clear who should be the next step (presumably from the dashboard/bucket?).

How do I reproduce unexpected results at the application level (for example, what's something I can search for that doesn't match but should match)?

Yes and no. So: maybe?

I want to resist adding additional actions here if they would be rarely used and reasonable workarounds already exist. After EditEngine (T11114), third-party extensions will also be able to provide supplemental actions.

There's a TODO about this in the code:

@Ondrej I was mostly trying to understand if you were seeing a regression, a mis-understanding of how Audit currently works, or missing some setting we should be trying against a default install. There were a number of variables still open based on your explanation to me at least, sounds like @epriestley has plans forward here though already.

• Chad, lets say I would rise a concern on your commit and I would never come back to Phabricator's website. You cannot mark your revision as closed. You need to remove me as an auditor and accept your commit (what is little bit complicated). What's more, there's no functionality to help me to follow this concern. When you commit a fix, how can you let me know about this fix?
• Epriestley, T2393 would fix the second issue, that would be great to have it today:-)!

(This change was half-accidental, and then I just figured I'd roll it into T2393 when I realized I'd made it.)

This did actually change in connection with T10978, but only if audit.can-author-close-audit is configured. I plan to resolve T2393 (maybe today?) and hopefully get rid of "Close" and this option entirely. I'm just going to merge this there.

if a concern is raised; no one except this auditor can close the audit.

We will also need reproduction steps to accept this as a valid bug report. See Contributing Bug Reports.

You're at least 6 weeks out of date. Can you update Phabricator and verify the bug at HEAD before filing, please?

I am unable to reproduce the issue you described by following the steps provided. To move forward:

Here's what I did to try to reproduce this:

The repository at https://bitbucket.org/LeCoyote/brokentest is enough to see unusual CPU usage. Of course, it is nowhere near as bad as the other one, but the CPU is still coasting a noticeable 2 or 3% above average, which seems disproportionate for such a small repo. Also, when calling the update manually:

$ time ./bin/repository update 3
Updated repository "cieltest".

Noted. I'll try and reproduce the problem with a different repository.

(A synthetic repository which you create by running hg commit in a loop, or instructions which allow us to build such a synthetic repository, are also fine.)

An existing, open source project is perfectly fine, provided you first verify that it reproduces the problem.

Unless you can make this task private to a group of people who would be prepared to sign a NDA in French, that's not going to happen.

We need specific reproduction steps to move forward, and "a repository with about 2800 commits" isn't sufficiently specific.

Thanks for the detailed explanation!

Yes, I've updated to 269dd81f91784d40abdd9af2d95061cdb3d2c394 and the issue is resolved.

Does upgrading past b21cd24341c6552a3fbd21305ca682a161129a6b resolve it?

making the old version of arc continue working as it did, if trivial, with new versions of the backend

based on the fact that 6 month old code worked fine until a backend upgrade last week, I'm guessing the breakage happened because of server-side changes

goes away after upgrading both to latest

After a quick look, ModularTransactions doesn't currently expose a shouldHideFormMail() hook and I may want to do something a little more tailored here, so fixing this isn't a one-liner.

For context, this is a side effect of the move to EditEngine in T11114.

Righty; I didn't want to create any extra noise. New ticket, ho.

Thanks, D17218 should fix this.

If you'd like us to look at it, please file a new issue following Contributing Bug Reports.

arcanist: ade25facfdf22aed1c1e20fed3e58e60c0be3c2b
libphutil: 9d85dfab0f532d50c2343719e92d574a4827341b
phabricator: 2d4eb460abb2ba34a944962c7cfea5741e099ff9