I believe there is very little reason for the "Autoclose" and "Publish" behaviors to actually be separate. That is, there are very few use cases where users want a commit to trigger only Herald or only feed or only audits. These use cases do exist (see T9210 for an example of "Herald, No Feed") but they're overwhelmingly niche and off-label.

In T13219#242865, @joshuaspence wrote:

I am seeing a similar issue on our install:

[2018-12-13 12:20:12] EXCEPTION: (PhabricatorClusterImproperWriteException) Unable to establish a write-mode connection (to application database "phabricator_repository") because Phabricator is in read-only mode. Whatever you are trying to do does not function correctly in read-only mode. at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:119] arcanist(head=stable, ref.master=d9a4293ae734, ref.stable=45a8d22c74a6), phabricator(head=stable, ref.master=2951694c2737, ref.stable=237a2a190984), phlab(head=master, ref.master=564c60d09ff4), phutil(head=stable, ref.master=dd136d1c3712, ref.stable=414a4c6abb1b)
  #0 PhabricatorLiskDAO::raiseImproperWrite(string) called at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:60]
  #1 PhabricatorLiskDAO::establishLiveConnection(string) called at [<phabricator>/src/infrastructre/storage/lisk/LiskDAO.php:1011]
  #2 LiskDAO::establishConnection(string) called at [<phabricator>/src/applications/repository/stora... (619 more bytes) ... at [<phutil>/src/future/exec/ExecFuture.php:380]
[13-Dec-2018 12:20:12 Etc/UTC] arcanist(head=stable, ref.master=d9a4293ae734, ref.stable=45a8d22c74a6), phabricator(head=stable, ref.master=2951694c2737, ref.stable=237a2a190984), phlab(head=master, ref.master=564c60d09ff4), phutil(head=stable, ref.master=dd136d1c3712, ref.stable=414a4c6abb1b)
[13-Dec-2018 12:20:12 Etc/UTC]   #0 <#3> ExecFuture::resolvex() called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:446]
[13-Dec-2018 12:20:12 Etc/UTC]   #1 phlog(PhutilProxyException) called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:453]
[13-Dec-2018 12:20:12 Etc/UTC]   #2 PhabricatorRepositoryPullLocalDaemon::resolveUpdateFuture(PhabricatorRepository, ExecFuture, integer) called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:222]
[13-Dec-2018 12:20:12 Etc/UTC]   #3 PhabricatorRepositoryPullLocalDaemon::run() called at [<phutil>/src/daemon/PhutilDaemon.php:219]
[13-Dec-2018 12:20:12 Etc/UTC]   #4 PhutilDaemon::execute() called at [<phutil>/scripts/daemon/exec/exec_daemon.php:131]

I am seeing a similar issue on our install:

In T12145#242682, @joshuaspence wrote:

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

I do have a real-life example where the prose diff engine rendered a suboptimal diff. I was able to fix it by changing the maximum length of the edit distance matrix from 128 to 256.

In T13208#242142, @epriestley wrote:

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

These reproduction steps don't work for me, and don't make sense given how the software works. If you believe you have a set of reproduction steps, can you walk through them step-by-step in more detail so I can reproduce the issue?

If anyone can come up with reproduction steps which actually work, this will probably take me about 3 minutes to fix. The only thing blocking this is that I have no idea how to reproduce it.

@epriestley, would you be open to making the chunk size configurable? Changing the chunk size from 32 to 512 reduced the amount of time required for us to lint ~1500 TypeScript files from 370 seconds to 66 seconds.

Even with OAuth, you still can't make AJAX requests to Conduit from client-side JavaScript, right? Is the idea that the backend code uses OAuth to talk to Conduit on a user's behalf?

FWIW, I am using a custom file and mail engine that utilises the AWS SDK and supports instance profile credentials. See P2082 and P2083. You need to install and require the AWS SDK before using these extensions.

Thanks for the detailed response, I certainly didn't expect it.

In T12959#230805, @chad wrote:

In general are you aware we no longer take bug reports or feature requests here?

In T12959#230799, @chad wrote:

What does "mysterious" mean.

I wonder if this OOM error can also be hit in other workflow though, given that it seems to occur in PhabricatorFileStorageEngine::getRawFileDataIterator.

Yep, agreed that the re-targeted proposal is a better solution... I had just assumed that this was a documentation oversight.

In T12950#230520, @chad wrote:

Why did they need regenerating in the first place?

I'm seeing these errors failing regularly:

I've got a reproduction case for this now: https://secure.phabricator.com/differential/diff/44008/

@hach-que, did you end up implementing a solution for this?

I am also seeing this error and am trying to work on a fix.

Another correction, Puppet doesn't //need/ a dedicated server. You can run Puppet in a standalone (agent) mode, if you are willing to somehow get your Puppet manifests onto each host that you wish to provision.

In T12856#227621, @amckinley wrote:

Terraform Review
Pros:

• Written in Python, which everyone knows is superior to Ruby in every way

FWIW, I am actively working on a Puppet module for Phabricator, see https://forge.puppet.com/joshuaspence/phabricator.

AWS doesn't have a single device which can both listen for TCP on 22 (only ELB) and terminate SSL for websockets (only ALB).

Ah sorry, I should've made that clear. Yes, I am able to reproduce the issue on our installation.

In T12907#228951, @chad wrote:

This is not a test install.

Is there a way to exclude users/projects from a query? A user on our install has asked for a way to search for Differential revisions with Project X as a reviewer where the author is not a member of Project X.

In T1026#224714, @epriestley wrote:

I currently expect to revert this change and decline to implement the feature because it makes using Differential on a phone more difficult for left-handed users

Thanks for the very detailed response.

Yep, that's a better solution. In the mean time, we just updated all of our .arcconfig files.

@epriestley, if you had any thoughts on this it would be appreciated as this issue is heavily affecting our users. There is a workaround (update our .arcconfig files to point to the new domain), but we have a lot of repositories...

For git, is that because discovery only happens on the Almanac device on which the repository is bound to or is it because there is some sort of global lock taken for repository updates? I'm curious to learn more bout how this works.

Thanks.

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.