The db001 issue is still an issue, but the shard has managed to stay just under 80% for the last couple of weeks so we're not in any immediate peril. As followups, I think T12217 and T12218 better capture the broader issues here.

We haven't received any more information about this in a little more than two weeks, and don't know how to reproduce it so we can't move forward. Feel free to file a new task if you're able to come up with reproduction steps which work in a clean environment.

I think there are some more things worth doing here, but user profiles should be significantly more clear after recent changes. Here's @demo on this install now:

Oh we already had one of these

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

Presuming this is resolved since we haven't seen any evidence otherwise, but feel free to file followups if you run into issues or limitations.

We haven't received information that lets us reproduce this in about a week.

I scratched at the surface of T2794, but @chad also bought me a larger monitor so I can put more SSH terminals on it which should buy us another few weeks.

• Why do you track "percent complete"? What do you use it for?
• Is it actually accurate? Developers are notoriously bad at estimating project timelines, so I would naively guess that a "Percent" field would have almost no relationship to reality.

D17333 is a probable fix without needing to resort to a bunch of weird setInterval() juggling. I've pushed that here, let me know if you're still seeing the issue? If you are, does your JS console have anything in it?

Other than implementing arc commandeer, can you suggest two different ways we could solve the problem you're running into?

I'm having some trouble reproducing this -- I tried Safari and Chrome here and in my sandbox. You aren't using anything weird, right?

At some point, it's starting to be a lot of noise in the project, so we dup all these reports against the task tracking the root cause.

From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.

We could also implement "Mute Thread" in Phabricator, but I assume no one would be willing to click twice to mute a thread.

If we use SMTP envelope To, doesn't Alice potentially get multiple messages still (envelope "To: Alice", envelope "To: All-About-Alice@lists.company.com")? The list rewrites the envelope to go to all the list members, right? Or is there more magic there I don't know about?

One issue with one-mail-per-recipient is that gmail does not permit muting an email conversation if you are the only TO recipient.

In T12240#211112, @epriestley wrote:

To jump back further, the root-ier cause is that you're using mailing lists?

If we implemented T3980, could you create projects for mailing lists instead of "Mailing List" users, then do one-mail-per-recipient + private-replies and be generally OK?

T11050 describes a way you could work around this issue in some cases in the future, by resigning from the review (basically, saying "I'm not going to review this on behalf of Project 1 because user B is on top of it, so get it out of my queue"). That doesn't help if you want it in your queue but just not in the "Must Review" bucket.

Thanks for the report, and for including detailed reproduction steps. The were very helpful in reproducing and fixing this issue.

If you want to implement the rest of it with a ( trigger I can counter-diff you for a (( trigger.

the trigger was the main thing preventing me from implementing phurl

(D17331 should fix the outdated discussion of the option in Config.)

In the specific case of Phurl autocompletion, I'd be happy to review a change if someone wants to tackle it. The recent emoji autocompletion is probably a pretty good example to start from.

(It's still not possible to name a link X | Y, but I think we're no longer aware of any reasonable cases where this is important.)

I belive this was effectively resolved by changes connected to T7691. Specifically, if you had a page titled "A" at location "x", you previously needed to type [[ x | A ]] to get it to render the right link text. If you omitted the ... | A ... part, the link would just be named x.

In T5301#210596, @DemiMarie wrote:

What about triple backticks in code blocks? Code blocks can contain
anything, so I consider not being able to put three consecutive backticks
in them a bug.

Commentary on this is welcome, even just to say no it won't fly.

I think this is the same as T11543 but I'm going to merge that here since this one is a little cleaner. My current thinking:

haha good 🐱 👍

I imagine that the rest of the process will work like this:

AWS got back to me with essentially a form response that didn't address any of the particulars of our case.

In exchange, here is a cat on a mat trying to do some yoga. Not my cat, but she was at an airbnb I stayed at and my decision to not steal her came down to a coin toss

that's a great pup. 10/10

@pmatos, Have you seen the Providing Reproduction Steps page? What kind of instructions can we add to it to make it better?

@epriestley I understand it's upsetting for someone to report a bug like I did. The problem here is that having no experience with Phabricator internals or webapps, I have no clue how to even give you the slightest hint of how to reproduce. For example, in my case, I got as I mentioned a problem with the daemons. I needed some further help from your side to actually create a bug report that actually helps you.

Going to pass on this functionality as I think with the new configurable sidebar we're in a much better position. I'd rather keep adding features to it.

You're correct, using brackets makes the regex work, thanks.

For starters, this regex fails to work

In T5301#149071, @epriestley wrote:

T5397 is another copy of the pipes-in-tables issue.

You can use remarkup.ignored-object-names to prevent S3 from being marked up: S1 S2 S3 S4

This would be helpful; post-T4900: Workboards updating in real time this would let the workboard be a broadcast mechanism of progress on an office screen, for instance.

Sometimes people will "Reply All" and everyone will get two mails, one from the user and one from Phabricator turning their mail into a comment.

To jump back further, the root-ier cause is that you're using mailing lists?

In T12240#211108, @epriestley wrote:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

I don't think we have control over the SMTP envelope for at least some of of the APIs we implement, although perhaps I'm mistaken. In some cases I chose the non-SMTP version of things (e.g., POST some JSON) when an SMTP version was available since I mostly know how JSON works but do not mostly know how SMTP works. It's possible we could revisit those decisions and do more SMTP to get greater access to envelopes, although I'd guess not all adapters provide us envelope access.

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user.

We already attempt to do this -- are you seeing it not work in practice? Rough pathway is:

Oh, I didn't even realize that was a thing. I assumed SMTP went like "okay here is a message: <message body>".

Some more thoughts: even if we can't control the Reply-to in all cases, phabricator can look at the TO header and perhaps choose not to send mail if it looks like it was already sent to a given user. Of course, given the above, this is spoofable.

Unless I'm missing something, I think the instructions here cause X to receive two mails (they are on "To" for both).

Why is it important to see all the duplicates at a glance?

Here is a picture from this morning but she was a little confused that we were wasting time taking pictures (boring) instead of going straight to daycare.

Or, more generally, if we send two mails:

I think you don't need to rebuild the search index for that to take full effect. Although rebuilding it will change the content in the index in some cases, the new, more-tailored queries should match either version.

We transform x y into +"x" +"y" in the general case, but currently apply stemming to "a_b" and "c.d". This is because it's generally correct to stem "x-y", which is usually a hyphenated English phrase rather than a "constant" or "token", and correct to stem "z.", which is usually something copy-pasted with a stray period, not an intent to search for a token ending with a period, and the cases of "_" and "." got lumped in with those.

Interestingly, phabricator_maniphest maniphest_transaction gives zero results but "phabricator_maniphest" "maniphest_transaction" works. Seems like the underscores are a problem as much as the period.

Maybe phabricator should automatically try adding quotes to a search if the initial query returns zero results?

• We no longer send normal mail to unverified addresses. Consequently, mail sent between creating an account and that user verifying their address (for example, assigning them tasks) is now dropped.
• We no longer send "sorry, we ignored your mail because we don't recognize the address" replies if we don't recognize the sender, unless phabricator.allow-email-users is set.
  • I would like to eventually (post-Nuance?) remove this option, stop allowing "email users", and move away from "grey users".
• We no longer send a misleading error about "no default user" if an application address is not configured with a default user.
• This install now delivers outbound mail through Mailgun instead of SES.
• The queued backlog appears to have flushed.

Unfortunately, this is so far afield from our roadmap that we don't have room for this year, even under paid prioritization.

• I think this sends the recipients many copies of the email, particularly if they are on mailing lists? Why do you believe that users will receive only one copy of the mail if we send ten messages with their address in "To"?
• Are you sure "Reply-To" overrides "Reply All" in all major clients? I haven't tested this personally, but I can't immediately find any references to this behavior on Google. I believe we already use "Reply-To", so I would expect "Reply All" to already be a non-problem if "Reply-To" overrode it. My pre-existing belief was that "Reply-To" replaced only "From", not the entire recipient list, under "Reply All".

@epriestley I was just jumping on here to provide some simple examples and reasoning from my experience on our internal bug tracker (we don't use Maniphest). Note this isn't my bug. Just trying to help out someone by giving an example for reasons they could want this. I'm sure your response was well intentioned but does come off a bit user hostile. For instance, nowhere did anyone mention wasting time by having a constructive conversation about this. It gives the impression that you guys consider having to deal with the community is a waste of your time. And no one is arguing against the root problem concept.

Hello! Thanks for writing in. Please read and follow the instructions on Contributing Feature Requests and Describing Root Problems. We require these guidelines be followed for every task, this saves the upstream time and resources.

A sub-issue here is that we're bouncing a lot of email like this, for an exciting product called "Penisole" from reputable domain "bloggay.com":