Sorry, I was responding primarily to @chad there -- the preview is at the bottom. I've circled what I was talking about here:

(I believe we already show any changes that pressing the submit button will make to subscribers accurately in the preview. This wasn't always true prior to EditEngine and I think the preview/actual effect would sometimes disagree in weird cases, but I believe the preview is now always fully accurate. However, it's quite easy to miss.)

This isn't a valid bug report, and we haven't received new information in several days.

Sorry, we don't offer installation and setup help. See Support Resources for help understanding what kind of support is and isn't available from the upstream.

Resolved by D16415.

Another possibility is to not rename any of the resources and just do the rename at the display level. This is a little messy, and occasionally a little confusing (instance newname will still have databases, backups, etc., named oldname) but we can probably do a fairly good job of covering that up.

Thanks for the report! This should be fixed in HEAD of master, and promote to stable in a few days. Let me know if I missed anything or you're seeing other issues.

I don't really have a pathway forward on this that I like, so I'm just planning to do the one outstanding request for this manually as a copy operation and kick the can down the road.

I think that makes things fairly easy technically:

I broke this in D16360, on August 1.

Thinking about the S3 issue, It's probably better to just migrate all the file data to the blob store, rename the database (which we have to do anyway), then migrate it out of the blob store.

I'm running into a need for this to make automated export reliable, too, and don't really want to put a second copy of set -o pipefail in the codebase.

Yeah, I think splitting it out is reasonable. There are a lot of reasonable ways forward that make this more of a standalone app, and it's going to need its own storage to keep track of stuff you skipped, I think. We could probably shoehorn it into Config but I don't think there's any real downside/cost to splitting it.

There is no actual cost to the form having more fields though, right? It doesn't actually slow you down, it just "feels" more complex?

This has been live for several weeks without causing any apparent issues, so I believe we're in good shape.

It sounds like you really want Workboards to work exactly like Trello, not just to be able to customize the form? That is, if we let you simplify the form down to this:

This should be fixed in HEAD of master, and in the documentation on this host whenever it regenerates (every other rainy Tuesday during a full moon).

I'm just going to merge this into T5028 since I think that ultimately is essentially the same issue.

We are unable to reproduce this, and haven't received more information in about a week. Feel free to file a new task if you're able to develop reproduction steps which we can follow to reproduce the issue.

Why does having more fields make creating a task slower? I'm not able to create tasks any more quickly using a form with fewer fields.

(T8850 is vaguely related.)

Yeah, totally fine with replacing home. I think hitting this first and then having a way to skip it is good.

I like the installation / quick start split. Feels good to me for installs in general and should also give us good behavior in the Phacility cluster.

cluster.instance is only used when serving multiple separate instances from a single cluster (for example, when hosting Phabricator for multiple clients), and should normally be left alone. This setting is used in the Phacility cluster to make x.phacility.com, y.phacility.com, etc., work correctly. This is sort of confusing because we use "cluster" to refer both to instancing and redundancy/scale; both are "clusters" in some sense but we don't generally expect users to care about instancing.

This report lacks reproduction steps, so I'm not sure how to reproduce the issue. We can't fix issues we aren't able to reproduce.

Yes, that's correct.

Yeah, I think this is because of --format=%s. Some discussion in T5028, which is probably most of this.

I don't have any ideas on how to build a simpler reproduction case offhand.

Oh, sorry -- you won't be able to reproduce this particular issue in the Phacility cluster.

You misspelled my username but that's enough for me to go on, thanks.

Can you push a commit to rGITTEST on this server which reproduces the problem? Specify "Auditors: epriestley".

This may also be a good opportunity to fix T10423 since we'd end up testing the same code.

The first line of a commit is always interpreted as a commit title, so the behavior you describe is expected.

Also, thanks for providing pointers to reproduction cases on this install. Being able to fiddle with those commits locally was helpful in confirming the behavior of -M and -C with paths.

I think there are two issues here:

This is because we hate code reuse.

We need detailed reproduction steps which work against a clean environment, as described in Providing Reproduction Steps. We run our entire production cluster through CloudFlare so I'm unable to reproduce the issue as described purely by using CloudFlare.

No smoking guns in the access or error logs on admin. The cache/load theory may just be a goose chase, since I don't see any evidence of unusual load around that time.

These are sort of technically visible in Config → Settings History, by looking at changes to phabricator.application-settings. However, this is mixed in with all the other settings and the actual diff is pretty hard to read (includes all adjusted settings; has raw JSON).

• This constraint should be fixed at HEAD of master. We just missed the deploy so it won't go until the cluster until next week (around August 20). Let me know if I missed anything.
• Empty constraints should be fixed at HEAD of master (they now error instead of being ignored).
• buildablePHID vs objectPHID confusion and inconsistencies should be fixed in the future by harbormaster.buildable.search. If you want a skeletal version of this now to reduce API tweaks later, let me know and we can get one in pretty easily.
• Linking to pre-filled forms seems maybe not hugely useful in practice, with some small risk of social engineering attacks? Feel free to file a separate request if you have use cases I'm not thinking of or whatever.

Fix CORGI errors, check if that reveals any obvious indicators of instance information fetch issues.

READMEs are only rendered in the browse view:

Slightly easier is:

I was able to reproduce this, possibly, by following these steps:

No disruption is expected and there was no maintenance or known disruption at those times. Nothing jumps out at me immediately in monitoring, either, and I can't reproduce this by casually cloning stuff.

D16396 should make us raise a narrow error for "ids": [], "phids": [], "whateverPHIDs": [], etc., instructing you to pass a nonempty list.

I think fixing "ids":[] is trivial; it just works like that because we use the same Conduit type ("PHIDList") both for constraints and other things which can accept an empty array (like setting subscribers to [] to remove all the subscribers on an object).

(@yelirekim, just a heads up since whatever comes of this might impact you somehow.)

Great! It looks like we're down from about 18K to 3K on repo001 too, so it appears that this pretty much works as expected.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

This has promoted to stable and doesn't seem like a contentious change so I don't currently anticipate any need to keep this open or revisit it.

Personal Herald rules do not run for disabled users, so disabling a user will disable all of their personal rules.

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

The use case in that linked task is "using Remarkup to demonstrate the behavior of a different markup language", which isn't something we expect Remarkup to support.

Why do you want to link part of a word?