See also PHI22.

T12941 is a third case of a user with no mysql or mysqli.

The particulars in T8918 are slightly different, but the root issue (showing too much stuff to users with partial sessions) is the same.

This is vague and may not actually identify a problem; I don't plan to pursue it.

We've closed registration on this install, mooting this.

Dropping these doesn't seem to have caused any major pushback.

This presumably counts as "not much interest" or should move to Discourse now or something, maybe.

This seems to mostly be a matter of taste, and we already have behavior similar to the behavior of git, which seems reasonable.

We don't have reproduction steps for this and thus can't move forward.

This doesn't affect us, but more fuel on the fire -- XSS in example code which ships with PHPMailer (we don't distribute this code):

We appear to have survived this.

Per above, this is not a bug.

No one but me cares.

We kinda did some of this, it can live on in subtasks.

This appears to lack reproduction steps, so we can't move forward.

We aren't going to implement a bin/phd start-missing-daemon command.

What is the network speed of transferring a similar file (e.g., a 400MB file from /dev/urandom) via ssh cat <file>?

Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.

There's probably no reason for us to have color: ... on the <select />

Is this the current status here?

I'm just going to merge this into T10448.

This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.

I suspect this is actually more like: actions on Ponder answers are not covered by the "Ponder Questions" email preferences, because a "Ponder Answer" is not the same type of object as a "Ponder Question".

I think it should be possible to backfill this from the transaction record, but definitely a bit involved. Holding it until we do history (and major/minor versions) makes sense.

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:

@hach-que, did you end up implementing a solution for this?

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?

I am also seeing this error and am trying to work on a fix.

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?