I guess the Merchant version would be businessAddress or something since Merchants aren't normally billed.

I think we could reasonably do this:

An instance needs their own address (and some other information) on the invoice for tax purposes:

It looks like the underlying issue (T11469) was resolved through configuration changes, so we don't need to go any further here. We are writing this log now, but it could use more work eventually.

Another instance was reproducing this more frequently/reliably and reports that they're no longer seeing issues, and I haven't been able to reproduce it myself since the configuration changes. Presuming we're in the clear now, but let us know if you see further issues.

I think this is actually a bug between several of the 300 different pieces of scroll magic we have on the page.

I can't reproduce this by following the steps you describe. Here's a screenshot of this working properly for me:

In almost all cases, it's within a second or two of the push.

I'm going to merge this into T11330, but note that you can already do this via Harbormaster, as this install does (we build via Drydock, but you can run a "Make HTTP Request..." build plan instead).

D16744 should also improve SSH performance slightly, with a larger impact on larger instances.

This may have been the "MaxStartups" directive in sshd; if so, a partial fix is currently deployed (raising the limit on application load balancers) and a more comprehensive fix will go out tomorrow morning (also raising the limit on repository shards).

Awesome, thanks for following up. Let us know if you run into anything else!

I do not plan to ever let you reorder milestones.

This has been live for about two months without any substantive issues arising.

I don't plan to implement the rest of the feature request. Assuming drag and drop works correctly, I think this operation (reordering panels) is rare enough that using it is reasonable without introducing the additional complexity of duplicate controls.

It should show a pretty clear preview of what it's going to do before you drop, so I'm not sure how it could be unpredictable? I wasn't able to identify any weird/surprising behavior when I tried to reproduce this.

even sometime seems to me not properly working

I wasn't actually able to reproduce this -- were you, @chad?

Pagination isn't quite as simple as I'd remembered. Specifically, we do not expose internal pagination cursors to viewers today because doing so permits an information discovery attack that goes like this:

Broadly, I think the two above comments are expressing a mixture of two ideas:

The proposed behavior (no subproject columns) means that tasks could be in multiple different columns at different levels, since they'd be draggable normally on each workboard:

T11774 wants a "delete file data" transaction, which is reasonable.

This is working as intended, and not a bug. Administrators can not bypass policies. See the User Guide: Account Roles documentation:

I think this behavior is very good

This is also a potential problem in the general case, although the general case of this is very rare.

Broadly, most applications can execute Spaces queries cheaply by querying ... AND spacePHID IN (<list of spaces the viewer can see>) when Spaces are configured, which is efficient until some install decides to create 30,000 Spaces for some reason.

The reporting user configured debug.time-limit to get a stack, which confirms this is a Feed issue:

Here are slightly cleaned-up recent timeouts from the logs:

I'm going to close this since things seem to have at least mostly worked and installs have had a couple of weeks to yell at us if we blew anything major up, but let us know if anyone runs into further issues.

I can't remember if Phabricator already requires a confirmed e-mail address to do anything.

We can also let installs send us all their data, we'll decide if it's spam or not, then we remotely delete any data that we feel like deleting. But we'd have to charge like a gorillion dollars per message to make this sustainable today.

What sort of reliable and automatic solution are you hoping for? How could the system reliably, automatically detect that a user is a spammer or that a task assignment is unwanted?

After D16714, the problem tasks should complete cleanly.

This feature request doesn't describe a root problem. See Describing Root Problems and Contributing Feature Requests for help filing a feature request which we'll consider.

D16714 should fix this by adding an implicit byte limit.

Differential also currently does not substitute a diagnostic message when declining to inline a patch: it should. ("Patch is too big to inline because limit X is set to Y." or similar.)

An additional inconsistency is that the diffusion.byte-limit applies to attached patches, but the differential.byte-limit does not. There's some vague argument for this behavior (you "shouldn't" be reviewing patches which are so enormous that they can not be emailed) but consistent behavior is probably better.

Sorry, "tomorrow" definitely didn't happen. Looking at this now.