Yeah, this is likely the same as T11188. See that task for some additional discussion.

This should now be fixed in HEAD of master. Thanks for the report!

This should be resolved at HEAD of master. Thanks for the report and the detailed analysis of the issue.

D15133 (making array utility functions accept any array-like object) is a possible attack on this in the general case, but I'm just going to fix this narrowly for now since it hasn't been a frequent/common/recurring problem so far. A more general approach may be warranted in the longer run.

I can't reproduce this.

Yeah, I'm thinking maybe just a button/link somewhere that takes you to a page similar to this one listing "Refs":

Sorry! How could we rewrite Support Resources or Contributing Bug Reports to be more clear that we don't offer help diagnosing or troubleshooting issues like this?

The fatals should be fixed in HEAD of master. I'm going to retarget this task to clean up the actual method calls, but this should have no user-facing impact.

D16420 restores setIcon() as an alias of setStatusIcon() as a quick fix for the immediate issue, since I found at least two other affected interfaces (Drydock, Almanac) and am not confident there aren't more.

This was likely broken by D16418. I think setStatusIcon() provides equivalent functionality, let me take a look.

Yes, this is intended behavior. See T10262 for discussion. See T10262#158198 for comparison to other systems, many of which use the same approach to access control for the same reasons.

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: