I was writing a lot of "Custom Actions", so I built this wrapper around the form handling pattern that was replicated around a lot.

I'm observing same issue in current ChromeOS 55.0.2858.0 dev branch.
At the same time image paste works in Telegram web client (seems that they use contentEditable div instead of textarea)
Do you know whether it's a chrome os bug or google deprecated DataTransfer.items in new chrome's?

This is still logged as an EXCEPTION. Is DELETE FROM phabricator_repository.edge WHERE type = 39 a reasonable step to take, to prevent administrators unfamiliar with the non-fatal-ness of this from being worried?

I think "Waiting" doesn't actually count as "Running", because it's "Waiting to run again" after an exception made the daemon die.

To fix:

We don't normally accept bug reports on prototype applications (see Prototype) but this is a one-line fix.

I have installed Phabricator from official documentation and get the same problem. I didn't create a bug report as I don't know the production steps. The problem occurred when I have upgraded Phabricator in July.

Makes sense, these are old versions of software. I will test with more recent versions of both Windows and Outlook to see if the issue persists.

To fix this:

Or I should say, the amount of time that would be needed to get to Windows 7 issues, would negate the need to support it. We're two developers and any bug is competing with thousands of others.

We have no plans to support Windows 7. Do you have issues with more modern versions of Outlook?

Having the same issue. Seems to only occur on certain panels. Adding the panel in question to a column now creates a duplicate in the opposite column. Removing the panel from one column removes it from both.

With the .eml files, you could change the From: and To: headers and pipe directly into sendmail or similar MTA.
If that doesn't work, I would be happy to provide a VM instance to assist in reproduction.

We don't provide support for other installation guides. Please contact that maintainer or install Phabricator from our official documentation,

It's a persistent problem. I've already tried to restart the deamons, the OS itself, but the problem persists. Phabricator was installed in a CentOS 7.2 system following the steps in this link: https://www.vultr.com/docs/how-to-install-and-configure-phabricator-on-centos-7

How can we reproduce this locally? Do you have a specific version of Outlook / OS you are using?

This isn't a bug in Phabricator, then. Please review Contributing Bug Reports and Support Resources carefully for details on what we provide support with.

On the cache:

I have run to the same problem. I have restart the daemon multiple times to fix it.

I have run to the same problem. I have restart the daemon multiple times to fix it.

We use a text field for a 'reference number' which refers to tasks imported from bugzilla reference=bz123, or RT with reference=rt456

Is this a persistent problem, or one only around for a minute after you change a config setting or update?

I think this is the CSS that tries to cut off the titles interacting weirdly with other table CSS.

I believed this was semi-intentional, although the downstream report suggests it worked at one point, so maybe I just made a mistake.

In this case, use the AphrontWriteGuard::beginScopedUnguardedWrites() method to surround the block -- you can grep for usage, but it will look like this:

I've got the endpoint and controller set up, but I get the following error when I call PhabricatorFile::newFromFileDownload:

Click "home". to see your installed dashboard. This is the expected UI.

I tried with fields available in the upstream, so it can not be reproduced with vanilla up-to-date- copy.

Alright I've been able to narrow this down a little bit more. There's some error with how external/pear-figlet/Text/Figlet.php is smushing characters. Specifically lines 339-362 as well as the _rep($r) function. The equivalent function in the C code is here. I haven't been able to find an obvious discrepancy, but I suspect there's a subtle difference in how one of the regex functions is handling things or an error in one of the regexes themselves. This error also occurs with backticks and double-quotes:

All queues have emptied, and repo002 is back in a healthy range again:

I have that problem again. There is no relation between the file and the Diff. Don't know how that can happen...

rP9329e6a12d9f improved the rate at which the Herald queue is draining by approximately 10x.

I've moved the largest instance from repo002 to a new empty shard, which has put both shards into fairly reasonable range. Queues still aren't draining as quickly as I'd like/expect.

I moved the largest instance from shard 002 to shard 006. This took about 35 minutes, most of which was backup/transfer time. I hit a couple of minor issues, but things appear to have worked properly overall.

PHP 7.1 RC2 is now available, and the patch for async_signals was merged into what is presently the 7.1 branch.

I migrated a test instance, which appears to have worked properly. I'm going to run though things again, then move a large instance off repo002.

• Suspend the instance: Admin → Instance → Manage Instance → Suspend Instance
• Stop the daemons:

I've provisioned and deployed a new shard, but not yet opened it for allocations. I'm going to launch and then migrate a test instance next.

I let the queues drain for a bit overnight. One of the large queues is down from ~16K items to ~12K items in the last 8 hours, but I don't want to just let this sit for 24 hours to "resolve" it. I'm going to look at moving instances across shards instead, which is a capability we need to automate eventually anyway.

Is this reproducible using fields available in the upstream? How can I reproduce this issue against a clean, vanilla, up-to-date copy of Phabricator with no custom code?

We have defined that one. It is like our teams with the company. When new bug is created for example maps team, herald automatically sets the right person/team for the bug.

Where is "Platform--MUST-->" coming from? That isn't a field we provide in the upstream.

phabricator 51f8ec4487be02e290b1182a7cd5b4069fe7d49f (Tue, Sep 20) arcanist 9e82ef979e8148c43b9b8439025d505b1219e213 (Thu, Aug 25) phutil fa6519f4cea1c059bd381c20971cac413cc4760e (Thu, Sep 15)

@ksmith it's a Python script that you would run on your local machine. If you have arcanist setup for development it should be pretty simple to get it working. Ideally it would just be a plugin, but I didn't look into that approach yet.

Ok I have observed this now on this install, however only in the second haunt mode Z+Z:
https://secure.phabricator.com/D15067

Looking at improving the raw performance of bin/repository update, one fixable issue is that we run git for-each-ref three times:

I also identified an instance with a bad HTTP hook which had managed to queue up 8,000 tasks in the queue. These already have scaling backoffs and likely didn't contribute a meaningful amount of load, but we could perhaps find a more graceful approach to handling bad webhook URIs during T11330.

I disabled the keys of the user running 30 clones/minute and notified the instance administrator. This appeared to create some headroom; I reverted the daemon pool size limits to the default and we're draining the queues at a somewhat more reasonable pace now.

@swisspol, that's what this refers to ("From T11666"):

I don't know if this is related but since an hour or so, whenever I push I get an error even though the push appear to work (the commits show up in Diffusion):

$ git push
# Push received by "web.phacility.net", forwarding to cluster host.
# Waiting up to 120 second(s) for a cluster write lock...
# Acquired write lock immediately.
# Waiting up to 120 second(s) for a cluster read lock on "repo002.phacility.net"...
# Acquired read lock immediately.
# Device "repo002.phacility.net" is already a cluster leader and does not need to be synchronized.
# Ready to receive on cluster host "repo002.phacility.net".
Counting objects: 56, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (50/50), done.
Writing objects: 100% (56/56), 9.30 MiB | 1.84 MiB/s, done.
Total 56 (delta 32), reused 1 (delta 0)
# Released cluster write lock.
AphrontQueryException: #1364: Field 'messageCount' doesn't have a default value
To ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
   015051e..67b218b  master -> master
error: failed to push some refs to 'ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git'

A contributing issue is that one instance appears to be making clone requests for approximately 30 repositories per minute to this shard. This is easy to rate limit, but probably not easy to rate limit in a generalized, not-a-cluster-hack way.

@epriestley Did you see the AphrontQueryException: #1364: Field 'messageCount' doesn't have a default value problem too?

Hummm I don't know if it was a transient error or I just happened to magically fix it by force pushing to the repo, but git pulls now work again on my Mac and in CI.