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 public NFAA datasets. not-for-all-audiences is one of the recognized NFAA tags in TAG_NFAA_SYNONYMS, and that branch raises:
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:
- If
not-for-all-audiences is accidental or no longer appropriate, correct the metadata and let the normal update path run.
- If the tag is intentional and appropriate for the dataset, I would keep it. I would not remove an accurate sensitive-content label merely to recover Data Studio. In that case, the higher-information question for HF is whether this repository is intentionally covered by the current public-NFAA Viewer restriction, and whether there is a supported preview/exception route.
There 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, and larryvrh/PIPPA-TavernFormat whose Viewer is live. In the same endpoint check, those returned 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.
Why I think this is upstream of the Parquet/config path
The current Viewer implementation appears to make the support decision before normal dataset processing.
In simplified form, the relevant logic is roughly:
repo_info = get_dataset_info(...)
if repo_is_disabled:
reject(...)
if public_dataset_has_nfaa_tag:
raise NotSupportedTagNFAAError(
"Not supported: dataset viewer is disabled."
)
if card_explicitly_sets_viewer_false:
reject_with_a_different_error(...)
# only after the support checks:
# proceed into normal dataset processing / cache / job handling
That distinction matters because several failure modes that look similar in the UI actually produce different backend signatures.
For example:
| Case |
What I would expect |
| Repository itself disabled |
separate repository-disabled branch |
viewer: false in README |
explicit configuration-disabled branch/message |
| Unsupported/broken Parquet/config |
downstream generation/parsing error |
| Site-wide datasets-server outage |
broad failures, including controls |
| Public NFAA support check |
NotSupportedTagNFAAError / exact message you saw |
The public /is-valid documentation also makes this layer separation visible. It treats viewer, preview, search, filter, and statistics as Dataset Viewer capabilities, and explicitly lists “the dataset viewer is disabled” as one reason a dataset may be invalid there.
Separately, the Hub documentation describes viewer: false as an owner-controlled README setting. Your repository does not appear to be relying on that mechanism.
So:
"disabled": false in the Hub API
does not imply:
"viewer": true in datasets-server
Those are different pieces of state.
The NFAA behavior appears intentional in the public implementation
There is useful history in the dataset-viewer repository.
The relevant sequence appears to be:
PR #2822 — disable dataset viewer for 'nfaa' tag added the NFAA restriction. The implementation also accounted for removing existing Viewer cache state when such datasets were encountered during backfill.PR #2823 expanded/normalized the NFAA tag handling and made the externally visible error less specific, which helps explain why the API only tells you “dataset viewer is disabled” rather than “disabled because of NFAA.”PR #2835 later relaxed the rule for some private NFAA datasets associated with PRO/Enterprise ownership, while retaining the public-NFAA restriction in the implementation/tests.
The current operations tests still exercise the public-NFAA rejection path.
So the message you are getting has a surprisingly specific history behind it; it does not look like a generic catch-all for every Viewer failure.
Why another ordinary re-backfill may not change this
The other reason I would not put a simple flush/re-backfill first is that the current code appears to run the same support check from the update/backfill path.
Conceptually:
repo update / backfill
|
v
get current repository metadata
|
v
is this dataset supported by Viewer?
|
+-- no -> unsupported path / Viewer state removed
|
`-- yes -> normal processing/jobs/cache
So if the public-NFAA check remains true, another ordinary backfill is not obviously a way around it; it may simply reproduce the same classification.
That is also consistent with what you already observed:
README/config edit -> still disabled
fresh commit -> still disabled
Parquet delete/re-upload -> still disabled
wait for processing -> still disabled
Those attempts were still useful diagnostically: repeated fresh revisions make a one-off missed webhook or simple stale revision less attractive as the primary explanation.
I would therefore move “please re-backfill it” from the first hypothesis to a later branch:
If HF says this repository should NOT be rejected by the NFAA rule
-> then repo-specific datasets-server state / cache / exception handling
becomes interesting again
-> at that point a server-side reprocess/backfill may be exactly appropriate
The production counterexamples are the part I cannot explain from outside HF
There is a genuine wrinkle here.
At the same time I checked your repository, I compared several public NFAA datasets:
RicemanT/booru-essence-2026
-> 501
-> NotSupportedTagNFAAError
RicemanT/booru-essence-2026-images
-> 501
-> NotSupportedTagNFAAError
QianyueWang/openGov
-> 200
-> viewer: true
p1atdev/open2ch
-> 200
-> viewer: true
larryvrh/PIPPA-TavernFormat
-> 200
-> viewer: true
rajpurkar/squad
-> 200
-> viewer: true
The last dataset is just a healthy non-NFAA control.
For the three NFAA counterexamples, the live datasets-server revision headers matched the current Hub repository revisions in the same check. That makes a simple explanation such as “Google/search is showing an obsolete Viewer that no longer exists” unlikely.
So there are at least two observations that have to coexist:
A. Current open-source Viewer code/tests explicitly reject public NFAA.
B. Current production has some public NFAA repositories with a live Viewer.
From outside HF I cannot tell whether B comes from:
- an intentional exception or allowlist,
- a different production code/configuration path,
- migration/legacy state,
- another repository property interacting with the NFAA check,
- or some other datasets-server state that is not public.
I searched for a documented public-NFAA Viewer exception/allowlist process and did not find one, so I would not invent one.
This is the main reason I would phrase the conclusion narrowly:
Your repository’s exact error strongly matches — and is currently being classified by production as — the NFAA support path.
rather than:
Every public NFAA repository is always forbidden from using Data Studio.
The first statement has direct evidence here. The second currently has counterexamples.
One small update to the companion-repository control
You mentioned that RicemanT/booru-essence-2026-images was unaffected.
That may well have been true when you checked it. At the time of my later endpoint check, however, the companion repository was also returning:
501
X-Error-Code: NotSupportedTagNFAAError
So I would no longer use the companion as a healthy control for “metadata repo broken, image repo healthy.”
I would also avoid reading too much causal history into that change without better timestamps. It tells us the companion now hits the same classification; it does not tell us exactly when or why its Viewer state changed.
Practical decision tree
I think the lowest-cost path is:
Is the not-for-all-audiences tag accurate for this dataset?
|
+-- No / accidental
| |
| `-> Correct the metadata
| -> allow the ordinary update path to run
| -> re-check /is-valid and Data Studio
|
`-- Yes / intentional
|
`-> Keep the label
|
+-> Ask HF whether NotSupportedTagNFAAError is the
| intended production classification for this repo
|
+-> Ask whether public NFAA datasets currently have
| any supported Viewer/preview route
|
`-> If HF says this repo should actually be supported:
investigate repo-specific server state / exception /
cache / backfill behavior
This keeps the content-labeling decision separate from the Viewer implementation decision.
If you want to reproduce the important part directly, the public API checks are small:
curl -i \
'https://datasets-server.huggingface.co/is-valid?dataset=RicemanT%2Fbooru-essence-2026'
curl -i \
'https://datasets-server.huggingface.co/splits?dataset=RicemanT%2Fbooru-essence-2026'
The useful things to retain are the HTTP status, response JSON, X-Error-Code, and revision/cache headers.
If keeping NFAA means the full Viewer is intentionally unavailable
I would treat this as a product/design boundary rather than forcing the repository metadata to fit the Viewer.
If the actual goal is partly:
“I want people to be able to understand the schema/tags/metadata in the browser without first downloading the whole dataset”
then one possible design separation is to publish a genuinely non-sensitive preview/metadata derivative separately.
For example, depending on what is actually safe to expose:
main NFAA dataset
- full rows
- full content
- accurate NFAA labeling
separate non-sensitive preview dataset
- schema
- column descriptions
- tag vocabulary / aggregate counts
- synthetic example rows
- carefully selected non-sensitive examples
That is not an official HF workaround that I found, and I would not use it to sneak sensitive rows around the NFAA label. It is just a way to separate two goals if HF confirms that the full public NFAA dataset is intentionally outside Viewer support:
- preserve correct content labeling, and
- still provide a browser-friendly technical preview where that preview can honestly be considered non-sensitive.
If none of the real content can safely be separated, then a good dataset card plus schema/statistics may be the cleaner answer.
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.