My concern here is the specific request only solves a side-effect of the root problem, and not the root problem itself. We do not expect admins to have to create blogs for people. I would like to understand better what we can do in that case.

Linux Chrome dev channel 55.0.2859.0 (64-bit) have no issues with image paste.
Seems that it is ChromeOS specific issue.

After setting max_connections=1500 , the problem still happens some hours after running the instance.

Aside from that, I don't think it's too much of a stretch to say that as a general principle, permanent/irrevocable subscription to an object is tantamount to spam.

In T11687#195734, @chad wrote:

In my administrator/management role, I create a blog for someone else to write posts for

Why?

Specifically, a root problem would be how you got into this state to request this feature to begin with, not that you want the feature.

In my administrator/management role, I create a blog for someone else to write posts for

Sorry. I thought the root problem was obvious. I guess not.

this entire menu will likely go away

Please see Contributing Feature Requests and Describing Root Problems.

I think this didn't actually get handled in T10262, but should be doable now.

Thanks!

Did this ever actually work? it looks like we're still embedding links:

Unicode has a page of heiroglyphs but they don't seem to be supported yet on OSX.

Thanks for the quick reply. It seems to be an issue with an internal script here, not Phabricator itself, so you can disregard.

I've heard you are exceptional with pets.

This is probably 5 minutes of work, I am just incredibly unreliable.

Oh, we do this in column now. I guess it's not 4 hours of work for me :)

Actually, I don't think we can really style the numbers of a numbered list independently of the rest of the list. They aren't directly addressable with CSS and the approaches I've found for doing it rely on using counter(...), which I think is unreasonably complex for this use case:

I can't reproduce this. Here's a diff with a new file:

151 seems to be the common default.

We have seen exactly the same error on our instance today, since updating to master. MySQL max_connections was set to the default of 151.

max connections was set to 250 (default?). We bumped it up to 1000, which seems to have fixed the issue for now.

Ah! Thanks, we'll get this fixed.

See Contributing Bug Reports if this is intended to be a bug report.

@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

Does raising max_connections in /etc/my.cnf (or similar) and restarting MySQL resolve this?

I can confirm that this bug also happen on a local install with a few users (around 15)

GitHub also does this:

We made one change recently (T11672) but that should cause us to use fewer connections.

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

When rebooting the sql server, we get an error on:

The Web UI, in the Config > Core > phabricator.base-uri section it has the following:

搭建 emulator 的 code review

Please see Contributing Feature Requests for help filing feature requests. Thanks!

This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.

I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!

Presuming resolved by D16584. Thanks!

Submitted {D16584}

I've banged on this a reasonable amount locally without issues and the originating instance reports that this seems to have calmed things down in production with these patches, so it seems like this pretty much just worked.

There's a bunch of other Herald stuff we already do for this field so I'm just undoing the change from D14766, at least until someone complains that this field type isn't using the search logic they expect.

Yeah, go ahead and submit a patch. Thanks!

Minimum viable patch sounds good to me, but @epriestley handles all contribs. Not sure what he prefers here. Feel free to patch locally first and verify.

Pretty sure it was copy pasted from something else at the time; I don't believe I would have actually picked a glyph.

So I've figured out the underlying cause. Outlook is sending attachments without a Content-Disposition header. The current version of mimemailparser included with Phabricator completely ignores attachments without that header.

I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.