To reach this dialog, mash some text into the search field in the global menu bar, then hit enter.

In Settings → (Personal Account Settings) → Email Addresses, you can take several actions with email addresses associated with your account, including adding new addresses.

Phabricator ships with a chatbot, roughly documented in Chat Bot Technical Documentation.

I believe this was resolved when D14982 moved us to a first-party client. We now ask for region/endpoint explicitly and I think there's no way to configure the bucketname.amazonaws.com version any more.

This and a few other overly-chatty errors should be quieter after T11480.

I think most of these have been converted now, and the remaining stragglers are getting fixed up alongside other changes (EditEngine, third-generation APIs, etc).

I'm just going to close this since we've converted most of the Query classes by now and are fixing the remaining ones as adjacent work happens. These changes were just minor improvements to code clarity and there's no particular urgency to fully modernizing things, nor do we get to delete a bunch of code once we're done or reduce maintenance costs in a global way or anything like that.

This was indirectly resolved by the switch to prose diffs in T7643.

I think we got rid of this since it was kind of weird and overlapped a lot with tokens.

Actually, from T9899 it looks like we already require it anyway, so whatever.

This was resolved in conjunction with T8952.

I believe this is resolved with modern clustered repositories. secure has been spread across two hosts for some time now without encountering any of this.

Upstream-wise, T8250 should happen first.

We have config for this (remarkup.ignored-object-names) but the chatbot currently (by design) only uses the API, and there's no way to get this over the API.

I believe this was resolved as part of T8952:

Just reopening this so I don't forget about it since I agree about that last change.

Although this is cluster-related, it can be tested with a single database host and is probably not exceptionally difficult to handle better. Briefly:

In most cases, edits in Phabricator are preserved and displayed in a transaction log, similar to the one you are looking at right now on this task, where this very comment appears. The transaction log records a complete record of changes so it's easy to review what changed and when.

Is anyone encountering this on a https:// protocol install? I was plagued by this issue for a while and switched to https:// and it seemingly disappeared. Although I can't reproduce today on the http:// protocol either.

To build on what was originally suggested, you can have all your repos stop publishing events by running the following which will list all repos and put them back to importing mode so they don't publish events:

We really, truly need reproduction instructions that let us reproduce the problem in an environment we control. We're happy to accept this bug report and fix the underlying issue as soon as we're able to reproduce it.

Chrome Version 41.0.2272.89 (64-bit)

I'm reproducing this issue on a standard installation. As I said, here is our configuration

I think we're on fairly firm technical footing on some specific changes, which I can probably lay the groundwork for and hand off to you to populate:

I agree with that (and actually believed we already did that, see T11485 for me claiming that this is the current behavior). We'll change this.

@chad, what is the rationale behind processing the very first line of the git commit message (the title)? I can't find any reason to do so, the first line is always the title. If you just ignored the first line and not performed any extra arc processing, this issue would go away. What am I missing?

In T2549#25878, @epriestley wrote:

• I deleted the @mierle account.
• It's currently not possible to link a Phabricator account to more than one external account of a given type (where "type" is one of "Facebook", "Google", "GitHub", etc.). In hindsight this was an architectural mistake, but I didn't think about it at the time and left us with a mess to clean up. It will be resolved by {T1536}, which is a sort of umbrella task for remedying various missteps on the auth pathway. We've made some progress on that, but it will be at least a little while before it lands.

We haven't seen other reports of similar issues and can't reproduce this issue ourselves in a variety of production and development environments.

I'm going to close this since it's working as intended and was just based on a miscommunication -- the actions UI (above the comment text area) is not expected to show a preview of the effects of a change. Instead, the preview UI (below the comment text area) shows this preview information.

I am not suggesting that as a fix, far from it. That was hack I made to get it to work for me.

The problem is that the current code works for almost everybody; Adding reverse() will likely break it for everyone except for you...

@cspeckmim - I am on a Mac/Chrome. No plugins.

@chad I understand your insistence on the Steps to Reproduce for a public project like Phab. The reason I am vague ( can also be said about T10120 ) is that this is a very hard issue to reproduce reliably.

What operating system, browser, and browser plugins are you using?

We believe you're seeing a bug, but we can't reproduce it as described, knowing what you are doing differently than us is important. Reproduction steps should be thorough enough that we can follow them, step by step, and see the exact same issue as you are. Without being able to see the bug locally, we'll have no idea if we've fixed it or not.

These steps don't reproduce for me here, on Phacility, nor in multiple development environments.

@avivey - I have added the Steps to reproduce the issue.

Have you fully read Contributing Bug Reports? This ticket is missing most of what is required for a handling, primarily reproduction steps, as highlighted there.

Actually, this is probably not T10968, although perhaps it's something similar -- possibly bad behavior when generating inline diffs or diff attachments for mail? It should normally be very difficult for a TransactionPublishWorker to generate mail side effects multiple times.

I've now tried on MySQL 5.6.27 instead of MariaDB. The same thing - cannot create a project. This time the process results in 504 Gateway Time-out. I guess if I'm the only person reporting this issue, the problem might lie with my setup. What's puzzling my is that it's only with the projects. 60sec should be enough for the FPM to process this request, I guess. Thanks for looking into it.

Sorry for this mostly stream of conscious while I was debugging the issue. The main way to resolve this that I found was find the DREV that is being processed in the workers table and kill it. I think some underlying issue exists in how this is being processed but until I have more time to look into it I am happy with just running ./bin/worker kill --id 123

Reproductions steps :

It's also vaguely desirable if the bulk processes (deploy/upgrade) can explicitly prefill the disk caches after mass-purging, since a bulk prefill is significantly more efficient than doing a readthrough fill moments later when the daemons restart. This only smooths out API burstiness during deploys, though.

Sorry, we don't offer help diagnosing problems. See Support Resources for a list of what we do and do not offer help with.

Some other things that could use updates:

After more thinking, I'm leaning heavily toward just doing a "display rename":

I used the new support code in connection with a manual instance rename (see T11413) and it appears to have worked.