# Dataset viewer stuck in "disabled" state, need help
**URL:**
**Author:**  [@RicemanT](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FRicemanT)%5C
**Post date:** [August 28, 2026, 11:30am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdataset-viewer-stuck-in-disabled-state-need-help%2F179406%2F1 "2026-08-28T11:30:15Z")
My Dataset is: [RicemanT/booru-essence-2026 · Datasets at Hugging Face](https://huggingface.co/datasets/RicemanT/booru-essence-2026)
The dataset viewer / Dataset Studio disappeared and the server endpoints return:
→ {“error”:“Not supported: dataset viewer is disabled.”}
But the Hub API shows the repo is perfectly healthy:
→ “private”: false, “gated”: false, “disabled”: false
Card parses fine (configs: default → data/\*.parquet), and the data files
exist (data/danbooru.parquet, data/e621.parquet, ~41.7k rows).
I already tried:
- fixed/verified README frontmatter (incl. explicit configs: block)
- multiple fresh commits, including delete+re-upload of a data/\*.parquet file, and just random editing of words/spacing
- waited \>1h between checks (no cache hammering)
Control test: is-valid?dataset=rajpurkar/squad returns a normal healthy
payload, so I assume HF is still up? The stuck state is specific to this dataset.
Could someone flush / re-backfill the datasets-server state for this repo?
The companion images repo (RicemanT/booru-essence-2026-images) is unaffected.
Thanks!
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [August 28, 2026, 9:16pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdataset-viewer-stuck-in-disabled-state-need-help%2F179406%2F2 "2026-08-28T21:16:03Z")
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:
```plaintext
Hub repository disabled? -> false
Dataset Viewer eligible/allowed? -> separate decision
```
The current [`dataset-viewer` support-check code](https://github.com/huggingface/dataset-viewer/blob/main/libs/libcommon/src/libcommon/operations.py) has a dedicated branch for **public NFAA datasets**. `not-for-all-audiences` is one of the recognized NFAA tags in [`TAG_NFAA_SYNONYMS`](https://github.com/huggingface/dataset-viewer/blob/main/libs/libcommon/src/libcommon/constants.py), and that branch raises:
```plaintext
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:
```plaintext
X-Error-Code: NotSupportedTagNFAAError
```
and:
```json
{"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`](https://huggingface.co/datasets/QianyueWang/openGov?not-for-all-audiences=true), [`p1atdev/open2ch`](https://huggingface.co/datasets/p1atdev/open2ch?not-for-all-audiences=true), and [`larryvrh/PIPPA-TavernFormat`](https://huggingface.co/datasets/larryvrh/PIPPA-TavernFormat?not-for-all-audiences=true) 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:
>
> ```python
> 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](https://huggingface.co/docs/dataset-viewer/en/valid) 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`](https://huggingface.co/docs/hub/en/datasets-viewer-configure#disable-the-viewer) as an owner-controlled README setting. Your repository does not appear to be relying on that mechanism.
>
> So:
>
> ```plaintext
> "disabled": false in the Hub API
>
> ```
>
> does not imply:
>
> ```plaintext
> "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:
>
> 1. [`PR #2822 — disable dataset viewer for 'nfaa' tag`](https://github.com/huggingface/dataset-viewer/pull/2822) added the NFAA restriction. The implementation also accounted for removing existing Viewer cache state when such datasets were encountered during backfill.
> 2. [`PR #2823`](https://github.com/huggingface/dataset-viewer/pull/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.”
> 3. [`PR #2835`](https://github.com/huggingface/dataset-viewer/pull/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](https://github.com/huggingface/dataset-viewer/blob/main/libs/libcommon/tests/test_operations.py) 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```plaintext
> 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:
>
> ```bash
> curl -i \
> '/static-proxy?url=https%3A%2F%2Fdatasets-server.huggingface.co%2Fis-valid%3Fdataset%3DRicemanT%252Fbooru-essence-2026'
>
> curl -i \
> '/static-proxy?url=https%3A%2F%2Fdatasets-server.huggingface.co%2Fsplits%3Fdataset%3DRicemanT%252Fbooru-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:
>
> ```plaintext
> 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:
>
> 1. preserve correct content labeling, and
> 2. 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](https://github.com/huggingface/dataset-viewer) 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**.
---
**Author:**  [@negdev](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fnegdev)%5C
**Post date:** [September 19, 2026, 7:23am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fdataset-viewer-stuck-in-disabled-state-need-help%2F179406%2F3 "2026-09-19T07:23:32Z")
Thanks a lot for the detailed breakdown — this clarifies the situation much better than anything I
could infer from the Hub API alone.
Your diagnosis matches what I’m seeing: the dataset viewer isn’t failing at the Parquet/config
stage, but is being rejected earlier by the NFAA eligibility check. The public datasets‑server
response returning `NotSupportedTagNFAAError` confirms that the viewer is classifying this repo
under the public‑NFAA restriction, even though the Hub metadata shows `disabled: false`.
The part that confused me was exactly what you pointed out: other public NFAA datasets currently
have a working viewer, so the restriction doesn’t seem to apply uniformly across all NFAA‑tagged
repos. That’s why I wasn’t sure whether this was an intentional classification or a repo‑specific
state that needs correction.
Given your findings, I’ll stop trying README edits or Parquet re‑uploads — those clearly happen
downstream of the actual decision. The right question for HF now is whether this repository is
intentionally covered by the public‑NFAA viewer restriction, and if so, whether there is a supported
preview path for appropriately labeled NFAA datasets. If not, then a reprocessing or viewer‑state
correction would be needed.
Thanks again for the thorough analysis — this gives me a clear direction for the support request.