Almanac's is a bit tight too

This also touches T10333: if you drop below card Z in group G (say, "High Priority" or "Assigned to alice"), I think intent is always to end up in group G even if card Z has moved from that group.

When you drop a card into a column, we send something like "alincoln dropped card X into column Y below card Z" to the server.

oh ok, i guess we should... catch this error and give a give a friendly message?

These aren't really related from a backend viewpoint, even though they're closely related from a UX viewpoint.

I just tried again (reloaded tab first) and didn't see the issue... Which is puzzling because I had reloaded the page twice and saw the issue twice before filing this bug.

I can't reproduce this. Here's what I did:

I upgraded last Friday to 2604c5af55f654d36f8db2f080b96486c4572216, so far this exception has not popped up again. I will check again later in the week.

See also http://news.php.net/php.bugs/201680

Can you provide system information, since you're saying this is a system (7.1) issue? I'm not able to currently reproduce this bug.

(Upgraded from 5efbf4d74aa72c5a7d7f161ea8c5aa33ac0e3189)

Confirmed this is fixed after upgrading to 864d3984ebdb42b9a2670103ca3607342e46b7dc

In T12163#208938, @epriestley wrote:

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

I'm just going to rename Differential everywhere.

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

typeaheads are useless

(I think this only impacts Diffusion, not Differential.)

In Paste (and I think Differential), we scroll lines instead of trying to wrap them:

@20after4 we're going to soon have a similar mechanism (personal/global menu) for the homepage here as well.

Yeah, you should be good now. I'll look into the JS thing since we like money.

I probably did something dumb when changing over from master to stable (I'm the only one that administers this instance and I know we've never modified phab's source). I should be good to go on the version front now?

I'm now running on the following after performing last week's upgrade.

Yeah, I think I screwed something up when I switched from master to stable. After following the merge commits all the way down I ran into this commit:

Ah, that's probably from an earlier git pull. Each of those merges have two parents, like this in the most recent output:

I'm not entirely sure what I did here to screw that up.

According to that test, your server does not support InnoDB fulltext, so what you're seeing is expected: we keep the tables with FULLTEXT indexes on MyISAM if innodb_ft_max_token_size is not a defined system variable.

It looks like my server supports InnoDB fulltext search

Ah woops, looks like I searched for the wrong variable for InnoDB fulltext support:

Thanks for looking further into this @epriestley and sorry for the less than ideal bug report. Please feel free to re-title/merge/close as you see fit.

I don't think this is a stemming problem. Note that we MATCH(corpus, stemmedCorpus) against the query, so we're actually searching in the text "this is a test thi test". I wrote stemming so that it should never match fewer documents than an unstemmed query would -- definitely possible I got something wrong, but that's the intent, at least: stemming only gives you more hits.

I can get around this by just hashing some unique string that makes up the error and dumping that into the task description and search off of that since full-text searching for single strings works as expected.

When I ran into this issue, I was attempting to automatically file tasks when my application encountered some unknown exception/error. I didn't want to file duplicate tasks for the same errors, so I was first going to look up the task name that followed some standard format like Error: <file> <line> .... I was testing with the string This is a test and was confused whythe conduit maniphest.search endpoint was not returning any results, but I could lookup other task names fine.

Can you describe how audit works in your organization and why you want authors to be able to close audits after T2393?

Do you have reproduction steps that are not hypothetical? I assume you actually ran into this as a bug, so knowing the specifics is important here.

@epriestley you don't want to know what schools teach/accept now-adays... is very scary.

My first internship I was tasked with working on an application as sole developer. It started at 8.6k lines in a Main.cs file and at the end of the summer I left with it at about 15.5k. Luckily we didn't do code reviews.

I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective.

Yes, your email explains the real behavior under the hood. I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective. Feel free to change title / description of course.

Does my email about refs/pull/68/head explain this behavior?

Is there some scenario which can trigger both bindings in a host group to be brought online?

A short comment now. Thank you for the very detailed reply.

What possible use case could anyone ever have for putting a THOUSAND lines of source code in a single file?!!

Without actually reproducing this or looking at the code, I believe this isn't a bug. You're expecting Drydock to choose particular allocation strategies:

Thanks a lot, the user should know what he was doing anyway.

D17242 should fix this, thanks for the report!

I confirm that the task is indeed created with the subproject tag and visible in its workboard when created.

There's now a grayed out page

Should I open a new bug?

Actually there's a bug with this behavior in the workboard, I can reproduce that in a test instance in phacility as well.

Reproduced on

Upstream doesn't support Phabricator installed via third-party images (including Bitnami). You need to reproduce the issue on either a blank Phacility test instance, or by following the Installation Guide and reproducing it there providing it's not an environment issue.

OK -- I made a new ec2 instance with the phabricator marketplace image to make the install easier. Updated to the latest stable and could still reproduce this. I don't know why the commit branches are saying that it is branched because I git reset --hard origin/stable on all the branches. I repeat -- this is a 100% fresh machine with the latest stable channel fetched from the phacility repos.

1. Create a task named This is a test
2. Search for This is a test, nothing found

This is exceptionally rare, strictly user error (i.e., avoidable by entering your email address correctly), and administrators can force-verify email addresses with bin/accountadmin which offers one way out of this state.