Hrrm -- I can adjust bin/mail send-test to accept raw email addresses, and then you can use it to send a message to test+00001@gmail.com, test+00002@gmail.com and similar. Shouldn't be too involved.

Here's a (not so great) workaround:

I'll send you some kind of something-or-other for dropping "Quality" from Conduit for the moment.

Internally, PHPMailer sends headers through two adjustment phases:

I know someone who has a normalname@domain.horse address and frequently finds services which won't accept it (since they're hard-coded for 3-letter TLDs) so I'd guess users with ={^_^}=@nekoneko.com addresses run into more frequent problems. We should handle .horse, .technology, etc., properly.

Can you test if this fixes the issue in your environment?

I think this is the controlling specification -- 2008 was a simpler time when no sequence of non-whitespace characters could ever be longer than 78 bytes, and a thousand bytes of memory was an untold wealth of riches:

I think the actual issue is that we're not wrapping the header. When I generate a synthetic message locally with a "To:" header with a length of ~50,000 bytes, the raw output is an unbroken line ~50,00 bytes long. I suspect this is RFC-violating and that whatever the mail gets handed to next gets upset by it.

Perfect, thanks!

What is metamta.mail-adapter set to?

See also T12046 for why all open source is sketchy voodoo and the eventual pathway forward here is likely replacing it with first-party code.

Two workarounds you could use here are:

(Are you associated with WMF, or just noting that they have an extension for this?)

Or maybe a better question is: @mrybczyn, are you asking on behalf of KDE, or a different project?

@bcooksley, is this another one of yours?

Thanks for catching this, and for the clear reproduction steps.

I have no idea either. We need reproduction steps. Reinstalling will not resolve this.

That is, the problem would be:

I guess we actually have to test this use case:

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

The general headers/sections are mostly scripted now so they should be fairly consistent, but I'm still editing the actual markup at the end of the day.

I think we currently get about equal amounts of "your changelogs should be more detailed" and "your changelogs have too much irrelevant stuff" feedback so I'll take that feedback under consideration but don't plan to make changes unless the overall balance of feedback shifts substantially in one direction.

We support viewerprojects() elsewhere but it isn't currently a component of the "Auditors" datasource. See also T9362#207080. I'll file a version of T9362 for the "Auditors" field.

I'm going to merge this into T5029. This is an extremely low priority for this upstream because this workflow is virtually unheard of among full-time software development professionals (see "Target Audience" in Contributing Feature Requests) because it is inherently error-prone.

How do you make guarantee that unrelated, simultaneous, uncommitted changes in the same working copy do not interfere with each other?

I haven't been able to reproduce this locally by artificially making services unavailable or connections fail. Debugging this in production will require momentary service interruptions on admin until I can narrow things down so I'm going to wait until off-peak to poke at it.

There isn't enough information here for us to reproduce this, or even begin.

You can adjust the validation here:

I think that's right, yes.

Users do count, but I thiiiiiink user mentions are a special kind of mention because they have more complicated rules and you can't read them with edge.search today. T4654 discusses better rules around "notify me when I'm mentioned"; there are some related Conpherence-specific tasks too.

Sometimes, Apache is configured with a rule which prevents any access to any URL which contains /..

courageous 🎆

I dropped the cache, looks like they're working.

Specifically, I suspect it won't affect repo because db restarts separately, so the database won't be unavailable when daemons on repo restart.

It looks like this might be an issue with MySQL not being available yet when the daemons start. The deployment script restarts MySQL, then immediately restarts the daemons, and a bunch of this stuff is ending up in the log in the 1-2 seconds after the restart:

I believe that's unavoidable with offset-based paging (the solution is to switch to cursor-based paging, but I think we can't do that for fulltext).

🍞 🐦

fancy 👑

I think bin/cache purge --purge-user will do it (but for every user). There's no way to do it for just one user, I don't think.

I've implemented a new edge.search API method. This method generally works similarly to other *.search API methods:

This should now be fixed in HEAD of master. Thanks for the report!

Here's the intended behavior from the source:

The build system should be able to call Phabricator via Conduit and ask for revision status today if you want a short-term fix.

Hrrm, it looks like my reply to your email bounced. Short answer is that we don't offer anything special for academic or open source right now. We'd like to in the future, but are focusing on building our core business first.

(That is, the expected failure mode of this query when it fails to scale is "silently return an incomplete result set", not "be really slow".)

To start with here, let's identify exactly what's slow? It's not clear to me from the downstream task unless I'm just misreading, and not evident to me from reasoning about the behavior of this query. This query strategy is fundamentally not scalable, but I would not expect it to be slow unless the ElasticSearch query is slow.

The results are ordered by "match strength", but this is computed at runtime and isn't unique to each result: we can't start with the 100th result and use it to build any sort of clause like WHERE rank > 12345 that starts on the 101st result.

Sorry, this isn't a feature request we can accept. See Support Resources for help understanding what kind of support is available, and Contributing Feature Requests for help with feature requests.

See T10109. I'm going to merge this into T2543.

You've personally observed a build trigger as the result of a user choosing "Plan Changes"?

The document contains "bash". This behavior seems correct to me.

This should be resolved at HEAD of master, thanks for the report!

Something like:

We've implemented a basic version of this, roughly along the lines of the recommendation above. Here's how it works:

(I think I've used this workflow fewer than 5 times outside of testing, and although similar workflows like "Award Badge" and "Add Project Members" have the same issue, I think they're similarly rare.)

This is also nontrivial: when we display a dialog, we already attempt to focus the first input. But the first input here is a tokenizer, not a real input, and naively focusing it fails because it hasn't activated or rendered yet.