The second issue causes the error #1054: Unknown column 'epochModified' in 'order clause' (note no ft_doc) which isn't exactly the same as the first issue.

I think this is a couple of different issues:

When you use the "Query" field to activate Ferret fulltext search, a "Relevance" score is computed internally. Roughly, today: documents are more relevant if your terms appear in the title than if they appear only in other fields; and stemmed terms are more relevant if the exact term you searched for appears in the raw document than if the stemmed version appears in the normalized version of the document.

PHI379 describes a weird "Copied Lines" signal which can at least be triaged.

As a note, pv can rate limit a pipe and is generally very useful all around.

this is a very good task :)

i used gem install so that i could remain ignorant of those types of problems

haha

I suppose welding does normally take a long time.

it has an -s option

There is a program far superior to cat that already exists.

Testing any of this is also a pain right now, so before any of that happens I'm going to write bin/harbormaster build --log output.txt or bin/harbormaster write-a-log or something. This overlaps the actual API-writing request in T9124, but that has more complicated concerns (like UTF8 issues, writing to a closed log, etc).

maybe a "grep" would be nice

I'm planning to tackle the build log stuff first since it's the most clear-cut, all fairly close together, and also roughly the most dumb.

Once I get an answer on how to submit it... See T12785

The build itself can do this over Conduit. Although it's possible we'll support things like this some day, I think this is currently too niche and disconnected from other application behavior to pursue in the upstream.

See PHI385. I think I stabilized the dashboard arrangement issues in D19123, but the arrange workflows are still in somewhat rough shape.

That is, we mutated the object outside of the Editor, then relied on the Editor to save the mutation.

Another option could be to only allow lowercase letters in the json specification, with some kind of warning message

One overarching issue here is that facts don't have a clear permissions model. It's bad if anyone can go look up the burndown chart for #critical-security-issues and then correlate that chart against tasks showing up in #weird-things-that-happen-when-you-hold-down-the-letter-a or whatever and get a hint about a security concern. In the general case, charts like "Salary by Employee", "Acuisitions Affecting our Stock Price", etc., are also potentially problematic.

• Fact cursors are currently per-object. I think they should likely be per <object, engine> pair so that subsets can be rebuilt more quickly for testing/development and the failure of one engine will not stop all other engines from processing data. On the other hand, fact processing is currently pretty fast and I don't expect to write a ton of engines so I'm not sure how critical this really is. Engines likely don't care how cursors work unless they depend on facts extracted by other engines and need to guarantee they execute later.
• FactEngine->getFactSpecs() isn't really authoritative -- it takes a fact definition externally. I think this should become the authoritative generator. That is, this piece of code needs to go sooner rather than later:

The company I work for doesn't use Phabricator anymore. If I recall correctly the issue happens when an error occurs when creating the working copy. So DryDock create a copy 'copy-123' for example and then if an error occur (during the creation of the working copy for example can't fetch the repository), the build is stopped and the folder 'copy-123' is not deleted. DryDock will retry after 15s and create another copy 'copy-124'. So you can end up with millions of folders after a couple of hours.