For now, I just hard-wiped the cache and regenerated the documentation again. ¯\_(ツ)_/¯

The file cache says that these files have already been parsed and contain no atoms, so the rest of the program behavior is expected after that. I'm not sure how this state came to exist.

• DivinerPublisher->publishAtoms() is being passed nothing, so it's correctly deleting everything.
• The graph cache is empty.
• The actual atom.cache file on disk is empty.
• The input to the cache is empty.
• The files aren't being passed to the atomizer rules (although the rules appear to be applying correctly).

So, so far it looks like the database is in a "good" state but the publish workflow incorrectly deleted all the articles. From previous efforts, I believe dropping the cache fixes this issue.

But note that the graphHash and nodeHash columns are 0, which I believe is a signal that these nodes have been deleted (I haven't touched this code in a while).

Oh, the contrib stuff got separated into a different book and has fully unpublished:

The "Contributor Introduction" document, specifically, seems to have unpublished. Let me see what I can dig up about the current database state.

"Yes", but post- T13098.

@epriestley, would you be open to making the chunk size configurable? Changing the chunk size from 32 to 512 reduced the amount of time required for us to lint ~1500 TypeScript files from 370 seconds to 66 seconds.

In retrospect, I should have rigged the hash for the the "Remove libphutil" commit to have some cool recognizable prefix like de1e7ed, since half of arcanist/ now ends up there on git blame.

Also, guess what this checkbox does on Windows 10?

Consider this script:

This was almost certainly resolved by D16273.

No clue how to reproduce this.

I believe this is essentially just T13209.

Changes in T13209 make this the only mode.

D11688 implemented this.

...we currently can not suspend instances through the web UI. The non-hacky way to fix this...

I think I'm done for the night, but we're down to 18 failing tests under Windows.

PHP7 introduces random_bytes(), which is a more accessible pseudorandom source on Windows than the other sources we use.

ArcanistLinterTestCase->lintFile() has a bug where it does this:

A lot of tests fail on Windows if core.autocrlf is set to convert "\n" line endings to "\r\n" line endings on checkout, which is the default behavior. In theory, this is fixable, but I'm not sure it's really worthwhile. At the least, I first want to get things passing without dealing with these tests.

Evolved into T13209.

It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.

On startup on Windows, arc currently complains that cURL isn't enabled. It gives you some okay-ish instructions for enabling it.

I'm currently trying to update my Surface Pro so I can look at making arc unit in the wilds branch pass on Windows. I've restarted to install more updates about 5 times, am currently stuck at "Feature update to Windows 10, version 1803 - Downloading - 0%" which appears to just be not working.

There should be no code anywhere in Phabricator to delete saved queries. The expectation is that they are never deleted or garbage collected because they may have been embedded in other pages, sent via email, etc., and deleting a saved query will break any use of the link in a permanent/external context. The table is expected to grow without bound, although at a slow enough rate that it does not create a maintainability issue.

In T13208#241647, @epriestley wrote:

[..] the issue is actually with persisting the query in the first place, not deleting it?

Could it be that a user assigns it to one of their "personal" custom queries and then later they delete that query by way of the maniphest saved query ui?

I'm not sure what's caused this either but I've seen it twice on wikimedia's production install.

welcome back little comment border :) you have been missed

I cut the Week 39 release with that stuff and am deploying it to secure now. I'm going to send it to repo006 if that goes cleanly to deal with PHI894.

My expectation is that no upstream code exists to ever delete saved queries. My guess is that either: