I can't reproduce this. Here's the first repository (I/O off, disabled);

I don't think the behavior of the fields is unclear and we haven't seen other users run into this particular difficulty.

Unfortunately, we can't help you with this problem. We didn't write this script, do not maintain it, and have never seen it before. You should try getting in touch with the script maintainers instead. We don't have the resources to provide support for third-party code.

OK, thanks. Because there is no documentation about what any of these choices mean would you like to make this task a documentation fixing issue?

Code being owned by a package does not tag it with a project.

D15977 improves some behaviors slightly and adds more extensive logging for signal handling. I don't think I caught anything with real meat to it.

D15975 should fix the (Exception) No such daemon "39084:6ra7uz"! error. I'm not sure if it will do anything for stability or not, but it should reduce noise. I didn't uncover anything interesting in resolving it (it wasn't really even a race, just a fairly straightforward set of state management bugs).

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Please read Contributing Bug Reports carefully and make sure you provide all the required information, particularly reproduction steps (see Providing Reproduction Steps). Thanks!

Confirmed workaround: set base project edit permissions to something other than Project Members.

@sascha-egerer that would seem to be the main factor, and the reason this couldn't be duplicated initially. It isn't all milestones - it is specifically milestones for projects that have subprojects.

Commit objects are not GC'ed in Phabricator?

Deleting the branch first won't have any effect, since the commit still exists.

Deleting the branch first won't have any effect, since the commit still exists.

Sounds like a dup indeed. What's the work around?

• Doing a rebase instead of FF-merge?
• Deleting the topic branch in Diffusion first, then FF-merge and push?

We have a somewhat-legitimate technical reason for this behavior: when we compute which-packages-own(list-of-paths), we do so by splitting the paths into components and then querying for the components. a/b/ is the best database representation for this.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

Is this the same as T6522? I'm not sure where the last screenshot came from, I wouldn't expect an FF-merge + push to trigger another evaluation of Herald rules.

Great, glad things are working. Let us know if you run into anything else.

Looks like that value was removed when the update happened as it was there before (checked with a backup).

Should be as I've only used SSH for the hosted repos - I will double check now.

Does your configuration satisfy the conditions described in the documentation?

This service has no relationship to Apple Computer Wiki, and can not help resolve your problem.

@CodeMouse92 yes the project has a subproject. But changing the policies as described above works around that issue.

I just looked the description in 74e117ae41dd.

In T11012#176923, @chad wrote:

We require reproduction steps on all bug reports, this way we know we're fixing your actual bug, and have a means to test and verify any fix. As Owners was recently overhauled with many new features, it's hard to identify what case we may have missed in testing.

I understand that. Will try to find reproduce steps.

I have not found a concrete way to reproduce it. Sometimes the status is correct and sometimes it's not and I can not find any difference on those commits yet.

In T11012#176731, @chad wrote:

This may also be T11015.

In T11012#176668, @chad wrote:

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

This is because that credential is in a restricted Space so this is ultimately the same as T9771, I'm just going to merge it there. The actual Query looks to be implemented fine so I think this is purely a Space issue.

I know this was linked against my question, but I wanted to check and see if it is the same thing...

Thanks!

This seemed to fix the issue:

From the server logs:

Phabricator version is rPe1ad312fdd2c570eeaacd3e02eda2142cc5d9849.

ref T9412

That sounds like it might be what's going on. I apologize for not having better steps to reproduce; I'm working backward from example emails that folks are receiving, so it's been a bit of a guessing game as to how to make this happen.

I think I have a pretty good guess about this one.

Can you be more specific about the steps to reproduce?

1. manually restarted php5-fpm and phd services
2. colleague, member of ops submitted review touching src/ansible
3. that review doesn't explicitly list "ops" as blocking reviewers because he's also an owner of ansible, but it does highlight my review in yellow
   
4. he lands it after I accept it
5. his commit is flagged for review despite both of us being members of ops

I will manually restart everything and reproduce again

Before I dig into this, is there any possibility this was a daemon running old code? I don't remember if I tested this explicitly and it could quite reasonably be an upstream bug, but the code at least attempts to check for this, and D15939 theoretically fixed issues with this.

This may also be T11015.

Yeah, current behavior is garbage. Not sure if I changed it by accident while doing other changes or we just didn't run into it before, but there's no technical or product reason for it to work like it currently does.

I ran into an identical issue (and debugged on chat). Agreed that there could be better messaging around this.

that worked. there's no indication in the UI that the trailing slash is required, the link rendered works fine

Try /wsl_root/src/ansible/ (with a trailing slash)?

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

I apologize, my ansible deploy script *should* have restarted everything that needs restarting, but it appears it didn't.

The following queries are full table scans:

Did you restart all webservers/php-fpm/etc. after upgrading? Did you upgrade the storage?
I cannot immediately reproduce this - see Contributing Bug Reports for some more information that can help you.

Did you fully restart everything (see Restarting Phabricator) after upgrading? I can't reproduce this and it looks like the kind of thing that could happen if Phabricator was not fully restarted.

Presuming resolved by D15710.