The support cost for the current behavior is very small. The behavior of the system is obvious. Users can file precise tasks like this one which clearly describe the problem (or find this task):

This behavior is intentional; it allows users to use a credential to configure other applications without actually having access to the plaintext.

Great! I think the Herald rule is also reasonable to build down the line if some future user arrives here via search and has a different use case for it in the future.

That did the trick, thanks!

This is awesome! I would've never found the ability to ignore emails from a project on my own. That's just the feature I needed to set this up correctly. Thanks guys for pointing me in the right direction.

Thanks for the quick response. I'll let you know as soon as the change gets merged into stable.

Of course! Thanks for poking around!

The constants aren't interchangeable no; one is a constant for the Harbormaster artifact type and one is a constant for a Drydock resource type. They're two different sets of types.

See edit for clarification.

I received this e-mail recently:

We have started to encounter this as we use phabricator in a devops environment with many teams from a large organisation.

Two-way.

Will this be a one way or two way bridge?

There are several classes of transaction like this. One is that all actions are restricted:

Will try to get more details for you from colleagues.

(And thanks for providing access to an environment where the issue reproduces!)

@Mnkras, I think I've undone everything I did and terminated all sessions on the host. You can revoke my key at your convenience.

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

T11270 describes a major issue with asynchronous signal handling in PHP 7 which I don't believe we have a reasonable workaround for.

I was writing my reply while you were writing the above. Just figured I'd mention it.

Yes, that's synchronous signal handling.

note that in the above we're explicitly handling signals. The signal_dispatch call must be placed inside of some activity loop.

function onsignal($signal) {

echo "Got SIGINT.\n";
  exit;

}

Just found another account disabled couple days ago which also says that doesn't belong to any projects, but some projects list him as a member. So the issue is in current version still present.

Yes, this reproduces on a local build of PHP 7.0.8. Here's what I did:

I'm building PHP 7.0.8 locally. In the meantime, I found these possibly similar reports:

Here's a smaller, self-contained test case:

I produced this test script to try to see about version issues via 3v4l.org, but you can't write files there. Requiring C as part of a different file is important, so I don't see a way to use that.

I put the global signal handler in run(), unresponsive.

I no-op'd the constructor and put the logic in run(), still unresponsive.

I disabled the entire actual daemon behavior, still unresponsive.

Removing the SIGINT handler entirely made it responsive.

I changed the SIGINT handler to exit immediately, still unresponsive to SIGINT:

This trivial script works correctly:

The PhutilNiceDaemon daemon also does not respond to ^C.

The debug daemon does not appear to respond to an external SIGTERM (via kill <pid> either).

With --trace, the daemon isn't doing any work, and also isn't hung (just normal queries to look at the queue).

I ran bin/phd stop and saw similar behavior:

@Mnkras gave me access to the host.

I can't reproduce that either:

Im really not sure, when I run restart this is what my daemon page looks like:

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

Given that I just received a useless eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board. email notification for this ticket, I suggest that T10745 be considered as part of email reduction.