I deployed D21062, and the three examples in the original report look good now. I checked about a dozen other pages and couldn't find anything else broken; let me know if I missed anything. Thanks for the report!

The second issue is that the API still returns a string when there is exactly one @attribute of a given type. This is a bit goofy; PhutilExecChannel is another example case.

I deployed D21061. First two example pages are good now, third one is hitting a different error. New trace is:

Docblocks may have multiple copies of the same @attribute directive, like this:

Here's the full stack trace:

The immediate issue now appears fixed and it seems likely that the root cause is also fixed. We should still hunt down the bad cache behavior in the presence of wonky permissions.

This cropped up again and the permissions error also resurfaced, even though I previously nuked the directory.

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.

I think a reasonable path forward here is for Diviner to have a {symbol} sort of syntax which executes a symbol index query. The symbol index can already be configured to know how to offer links to external documentation.

Per above, I think the pathway forward here is probably "tighter integration", not "merge/replace", i.e. tools for Diviner to automatically update Symbols, too. I'm just going to conceptually roll this up into T13047.

Embedding files by alias might be useful

Oh I see the problem with that

I've been locally previewing in Phriction.

I'd guess it's several days of work.

Is this hard to do? Can me accomplish?

+1 for random grepping. Thanks for the fix!

(Your diagnosis of the root cause was also correct.)

I deployed D17346 and rebuilt the indexes on this install with bin/search index --type DivinerLiveSymbol and behavior now seems correct. Thanks for the report!

I think the major intent was being able to edit "View Policy" so you could create private documentation, but I don't recall if we got that far.

You could tag a project I think, but not sure what that actually did.

Basically nobody is using Diviner, and I don't think the "Edit Book" page actually does anything useful.

I see the same behavior noted by @lianghu in T9042#129510.