I think this was caused by the issue resolved by D15072. Specifically:

This should probably happen in the next week, as it's creating moderate storage pressure on db005.

After rCORE538a9808, all new files larger than 64KB go to S3.

This was fixed by D14925.

I can't immediately reproduce this at HEAD but I'll poke around a little bit more.

This does not describe a bug in Phabricator. Please read Support Resources and Contributing Bug Reports carefully.

After D15093, this should be a little better:

After D15093:

(This is definitely confusing, but I'm not sure what the best way forward is offhand. I'm hesitant to just make Herald always trigger without putting more thought into the issue.)

Add a call to ->setPageSize(500) (for whatever value of 500 you prefer) here:

What sort of answer would you prefer we provide?

(See also Contributing Feature Requests and Describing Root Problems, and T8227.)

We don't plan to implement this.

From T10170, Ponder still has some addRawSection() calls which should be addRemarkupSection() calls.

This request does not describe a root problem. See Contributing Feature Requests for details, and Describing Root Problems for help describing a root problem.

The first hit on Google for "phabricator daemons" should be the documentation for them:

This would be ambiguous with other directives (lines, name, counterexample, etc).

We can't reproduce any of this and no other users have reported similar issues. Some of the issues described here are likely access/permissions issues, which should be communicated more clearly after D15079 / D15080.

This is probably because the user you are connecting with does not have permission to access the database.

I think case (1) (and maybe cases (3) and (4)) is resolved at HEAD.

Herald has some very unusual code to preserve control values when you swap the selectors. Generally, the issue is:

HarbormasterBuildTarget->loadArtifact() also probably does a table scan when it doesn't need to, but if that isn't causing any problems I'll leave it alone for now until we hit it for real.

I can't reproduce the second issue; that index should already exist (or bin/storage adjust should create it if it does not). Here it is in the source:

I believe this is fixed at head. Let us know if you're still seeing issues.

(And there are no configuration settings you can change which will possibly impact or resolve it -- it can only be resolved by an upstream fix to the problematic implementation.)

Sorry, I wasn't very clear -- I know exactly why this is happening. It isn't related to configuration or arcanist (it's an implementation issue related to D14970), so I don't need any more information.

Daemons now do both reads and writes, and may need to do reads and writes which are nonlocal in cluster configurations. So I think the pathway forward here must be to expose local disk storage over HTTP with S3-like raw APIs (read, write, delete).

Sounds good.

This is an issue in the implementation, not a configuration issue.

To the best of my current knowledge, there are no actual problems with the Node server (empirically, it is easy to install and maintain, stable, and works well) and no viable pure PHP alternatives anyway, so I have currently have no plans to ever pursue this. See above for a description of the type of new information which could affect these plans.

This has been open for about 18 months without anyone coming up with any really concrete use cases to motivate any of these flags, so I'm just going to close it out until such a motivation develops and this becomes non-hypothetical. I haven't seen any misuse here personally in the upstream, and we haven't heard too much feedback about this particularly, as opposed to some general difficulty finding the right projects in typeaheads, particularly for newer users.

These now show hovercards, which will show project information after M1455 is implemented. I'm just going to close this in favor of T10054, which is an umbrella task tracking related work.

These seem alright, I haven't been bothered by them.

I don't have any current plans to pursue this, per se, in the upstream.

You can now customize "Create" forms and prefill (and, optionally, lock) their policies. See: