There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think you're innocent and that it never worked but I only looked at it for like 2 minutes.

There may be a bug with the body versioning (maybe it got broken by accident when we swapped to ModularTransactions, or maybe it never worked), but if there is we should fix that bug. The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

Maybe I'll put it on A, I guess ("Toggle All"), so it's sort of near q, which is similar (collapse/expand).

If it's a toggle, what do you expect us to do if you press it with some inlines hidden and others visible?

See PHI14 for priority.

And one more.

The easiest fix is probably to add a TYPE_CREATE transaction into ReplyHandler or MailReceiver alongside the other creation transactions.

This is now formally prioritized (see PHI14).

Only db001 and db002 are anywhere close to having problems with this and they still have a large amount of headroom, and we can bin/storage optimize at least some amount of additional headroom into existence, so this isn't "we're about to fall off a cliff" urgent or anything, but would be nice to tackle sooner than later.

We've had two customers hit this (both for Kotlin, although a config workaround is available).

Is this a test or a bug report? If it's a bug report, how can I reproduce it?

That is, my expectation when you have set "Default Branch" to "mmmmmmmmmmmmm" and visit the repository page is just:

This is what it did in March 2016: T3607#163684

Where is the exception coming from?

I believe the issue here is:

I think the minimum size is 2 hosts, in separate AZs, in one region. e.g., everything1 in us-west-1a and everything2 in us-west-1c, so that assumption is sound.

Well, I'm half mistaken. What you're seeing is a bug.

(Oh, no, I'm mistaken.)

That's supposed to leave an "Undo" bar, still want us to fix the bug?

I think (?) this reproduces for me, too:

See PHI11. This has material impact when using PhabricatorRepositoryRefCursorQuery to query landing targets, and likely impacts the logic in DifferentialRevisionOperationController.

I'll look at the pricing breakdown and I might do some perf testing just to see if there's any real difference.

22280->22280 for aphlict (or we could possibly use path-based routing on the ALB instead of opening up a 2nd port?)

Cool, that all sounds like it's roughly what I expected. Thanks!

Let's just take another look at this during/after T10448? I think that's happening soon enough and this is minor enough that it's probably not worth fixing separately.

Inbound mail seems to be working now.

This is very minor, but blue-underneathie is still active even though repo012 is dead, which is causing the queue to spawn impossible backup jobs that sit there retrying forever. They should fix themselves once the instance is suspended. I'll likely pursue the remaining cleanup here shortly since we haven't seen any issues in a few weeks.

Inbound mail later bounced. I think the issue is that we have a *.phacility.com MX record, but an admin.phacility.com A record. I can't recite all the wildcard vs nonwildcard DNS rules offhand, but I think the A record is shadowing the MX record, e.g. dig mx admin.phacility.com does not produce the right results. I've added an admin.phacilty.com MX record which might sort things out once it propagates.

The new paid support application is now in closed beta. This will become publicly available in the relatively near future, then become then channel for SAAS support after that. It may later become the channel for some types of free/community support (most likely bug reports, per above) but this probably won't happen for a while.

Community and us can both use the normal task form to report bugs -- the "bug report" form just had extra instructions.

That is, the flow would be one of these:

Let's just do Discourse for now? I don't plan to get anything up on admin for at least a while.

Using @mentions in issue comments hits a policy exception because of the slightly odd way pact policy filtering works.

This works now: PHI1

Test mail from the console now gets routed/accepted properly but real mail still doesn't. I'm going to write this off as possibly being a route propagation issue for a little bit and see if it fixes itself.

Email replies don't actually work since mail gets routed to the web tier (mail.phacililty.com) which can't hit admin. I think I can fix this with a mail route.

Some stuff I'm thinking of doing in the short term:

This is entering some kind of closed beta shortly, I'll follow up in T12904 for actual feature improvements to the Support application.