Uh… I think the NFAA tag may be the suspicious part here:
The strongest clue I can find is that this does not look like a normal Parquet/config-generation failure or a repository-level disabled
state. It looks much more like the Dataset Viewer rejecting the repository at its support/eligibility check, specifically because of the not-for-all-audiences
tag.
Your disabled: false
observation is still useful, but it appears to answer a different question:
Hub repository disabled? -> false
Dataset Viewer eligible/allowed? -> separate decision
The current dataset-viewer support-check code has a dedicated branch for
not-for-all-audiences
is one of the recognized NFAA tags in TAG_NFAA_SYNONYMS
NotSupportedTagNFAAError
Not supported: dataset viewer is disabled.
That second line is exactly the message in your report.
More importantly, I did a point-in-time check against the live public datasets-server endpoints, rather than relying only on the GitHub source. For RicemanT/booru-essence-2026
, both /is-valid
and /splits
returned HTTP 501 with:
X-Error-Code: NotSupportedTagNFAAError
and:
{"error":"Not supported: dataset viewer is disabled."}
So for this particular repository, the NFAA path is not just a guess from the source code: the production service itself is currently classifying it that way.
I therefore would not spend more time on random README edits, whitespace commits, or Parquet re-uploads yet. Those were reasonable attempts, but if this support check is what is firing, they are happening downstream of the real decision.
The first useful branch is simpler:
not-for-all-audiences
is accidental or no longer appropriateThere is one complication worth mentioning: I do not think it is safe to generalize this into “all public NFAA datasets can never have a Viewer.” I can currently find public NFAA datasets such as QianyueWang/openGov,
p1atdev/open2ch
larryvrh/PIPPA-TavernFormat
200
with viewer: true
; their datasets-server revision headers also matched their current Hub revisions, so this does not appear to be merely a stale search-result artifact.That makes the target-specific diagnosis fairly strong, while leaving the production-wide semantics for HF to clarify.
So I think you have already supplied most of what a maintainer would need. I would stop perturbing the repository for now and focus the support question on this distinction:
The live datasets-server response for this repo is
NotSupportedTagNFAAError
, which matches the current public-NFAA support check. Is that the intended production behavior for this dataset? If so, is there currently a supported Viewer/preview path for appropriately labeled public NFAA datasets? If not, should this repository be reprocessed or have its Viewer state corrected?
The dataset-viewer repository recommends reporting dataset-page Viewer errors in the dataset’s own discussion, so this thread already seems like the right place to resolve the part that cannot be determined from public state.
At least from what is observable publicly, I would put NFAA eligibility first, ordinary cache/backfill second.