This task was filed via the "New Bug Report" form.
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 a bug, please?
Thu, Jan 19
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!
Wed, Jan 18
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