This is, uh, a... test case? Of, uh, missing provider config? Completely intentional!

Specifically, submitting ids: [[1]] will reproduce this:

I think we can only fix this by adding typechecking to Conduit, which will happen some day but is a larger project.

I'm not sure. Possibly, e.g., control-click the "Action" dropdown, type in a garbage key like "partytime", submit form normally? But it might be more clear if we knew the key.

It looks like this can happen if you try to apply an action which does not exist.

Try reading this, which is entirely about this topic:

This should be fixed in HEAD. I've pushed the change to this server if you want to try to catch any remaining issues before upgrading (we don't really use subpriority on this install, so don't worry about messing things up).

The behavior here was generally spooky and nondeterministic (see T5201, which had the same "spooky code" root cause), it just got even spookier recently. I think it should be more predictable after D12121.

I also guess I can build the actual instance-strip operation regardless of the central-account-strip operation, since if administrators configure only instance MFA then central MFA compromise likely allows an attacker some kind of access anyway (at a minimum, they can add an account they control to the instance as a member, which is likely nearly as bad as compromising an administrative account fully).

No. We do perform MFA checks if they enable it, but we don't currently require it (and don't have UI hints to suggest that they configure it).

I don't believe it is practical to modularize OAuth more than it is already modularized. OAuth doesn't define how to get information about user accounts (like email, account ID, profile picture, etc)., so the GitHub vs Amazon vs Etc choice is irreducible.

• For isRoom threads, you should be able to use $policy->getIcon() (on PhabricatorPolicy) to select an icon matching the policy that's consistent with policy icons elsewhere in other applications.
  • For non-room threads, the $policy isn't meaningful but you can easily special-case the icons.

Presuming resolved, yell if not.

Yeah, unless differential.sticky-accept is off (which is intentional).

I can't reproduce this, the revision immediately goes back into "Accepted" for me:

There's no way to do this right now. You can use the "Generic" icon until we eventually build a modular way to provide icons. This isn't a priority; see T5447 for some rough context and timelines.

Sorry, we don't accept feature requests for prototype applications like Calendar. This document explains prototype applications and why we don't accept feature requests for them in more detail:

I wonder if there's a way we can detect it. From the report and patch, it's not obvious to me how we could trigger it (to see if it segfaults), and we probably can't usually read /var/log/syslog (to see if there are logs of a segfault). I can't immediately find it in the PHP changelog, either, to just blacklist affected versions.

As specified, totally disconnected. It's just a room with "Visible to: Members of Project X", like any other object.

Sorry, misread. Ignore me. This is probably a bug on our side.

If you're sure other users can't see them, update to HEAD.

Yeah, I'm not sure what's up. We're slightly ahead of you (rPb7fa55ff) but basically running the same code.

I changed it to require authentication, just in case that's the issue -- set a VCS password in Settings > VCS Password and try again?

Hmm, try this one?

What error do you get if you try this?

Try cloning this? Does that work?

D12110 doesn't actually fix this, per se, it just gives you the correct error.

Overall, we can definitely improve the transcript view, but it will never be an especially good solution to this problem:

Suppose it worked like this:

it is a pretty cool GIF tho

Chunk engine is being incorrectly selected as writable in non-chunking configs.

It sounds like lint is a much better fit for this problem than Herald (for example, it won't raise warnings in comments, and it points out exactly where issues are, engineers get a chance to see issues before they get sent for review, etc) -- are there reasons it isn't that I'm missing, or reasons that moving these review rules to lint rules has been slow or impossible?

We're happy to solve problems you encounter, but want to wait until there's a specific problem. There's currently no reason to believe that there is a problem, and no reason to believe that a sitemap.xml is the best solution to any problem.

One thing I missed:

This should be fixed in HEAD. Thanks for the report, and let us know if you run into anything else.

I don't think this is a good addition because retires is a correctly spelled English word.

In particular, at Facebook:

Do you think the majority of these blocking reviewer rules are good, or is figuring out why blocking reviewers were added more-than-occasionally the first step in removing them? If these rules added normal reviewers -- instead of blocking reviewers -- would this be a problem?

I think I have this working locally and am nearly ready to give it a shot in the cluster.

Rough notes for eventually formalizing this:

Yeah, Phortune is generally a bit under-designed and dense-feeling.

Here's an example order detail:

https://admin.phacility.com/phortune/1/

Oh, that's the payment account (not the merchant account). The merchant account lets you refund charges, etc. I'll add you to the payment account.

Do you want to be part of the merchant account, or do you want to be able to pay for our instances?

I unlocked this task administratively. Please don't lock tasks.

There are not.

Some stuff I've left out, but which may be worth thinking about as the product gets more concrete or in a future update:

Okay, let me fix the fallback behavior and get it printing whatever the chunk upload throws and we'll see where that gets us.

Hmm, anything in the error log on the server?

If you run git diff abd09676fb35c063..HEAD, do you get the diff you expect?

It can't hurt to have a mock available, but it's unlikely that I can implement logos for merchants in less than an hour (because of T6670, this may actually be a day or more of work).

We can make these look different from other transactional email (but still general to Phortune) with a moderate amount of time, work, and ongoing maintenance cost.

For reference, here's what they look like today:

Can you show me the output of arc which, when run in a working copy in the same state from which you ran arc diff and got unexpected results?