Function load_dataset() misinterprets string field content as part of dataset schema when dealing with `.jsonl` files
State: open

### Describe the bug

When loading a `.jsonl` file using `load_dataset("json", data_files="data.jsonl", split="train")`, the function misinterprets the content of a string field  as if it were part of the dataset schema. 

In my case there is a field `body:` with a string value 
```
"### Describe the bug (...) ,action: string, datetime: timestamp[s], author: string, (...) Pandas version: 1.3.4"
```
As a result, I got an exception 
```
"TypeError: Couldn't cast array of type timestamp[s] to null". 
```
Full stack-trace in the attached file below.

I also attach a minimized dataset (data.json, a single entry) that reproduces the error.

**Observations**(on the minimal example): 
- if I remove _all fields before_ `body`, a different error appears,
- if I remove _all fields after_ `body`, yet another error appears,
- if `body` is _the only field_, the error disappears.

So this might be one complex bug or several edge cases interacting. I haven’t dug deeper.

Also changing the file extension to `.json` or `.txt` avoids the problem. This suggests **a possible workaround** for the general case: convert `.jsonl` to `.json`. Though I haven’t verified correctness of that workaround yet.

Anyway my understanding is that `load_dataset` with first argument set to "json" should properly handle `.jsonl` files. Correct me if I'm wrong.

[stack_trace.txt](https://github.com/user-attachments/files/21004153/stack_trace.txt)
[data.json](https://github.com/user-attachments/files/21004164/data.json)

P.S.
I discovered this while going through the HuggingFace tutorial. Specifically [this part](https://huggingface.co/learn/llm-course/chapter5/5?fw=pt). I will try to inform the tutorial team about this issue, as it can be a showstopper for young 🤗 adepts.

### Steps to reproduce the bug

1. Download attached [data.json](https://github.com/user-attachments/files/21004164/data.json) file.
2. Run the following code which should work correctly:
```
from datasets import load_dataset
load_dataset("json", data_files="data.json", split="train")
```
3. Change extension of the `data` file to `.jsonl` and run:
```
from datasets import load_dataset
load_dataset("json", data_files="data.jsonl", split="train")
```

This will trigger an error like the one in the attached [stack_trace.txt](https://github.com/user-attachments/files/21004153/stack_trace.txt).

One can also try removing fields before the `body` field and after it. These actions give different errors.


### Expected behavior

Parsing data in `.jsonl` format should yield the same result as parsing the same data in `.json` format. In any case, the content of a string field should never be interpreted as part of the dataset schema.

### Environment info

datasets version: _3.6.0_
pyarrow version: _20.0.0_
Python version: _3.11.9_
platform version: _macOS-15.5-arm64-arm-64bit_

Comments:
Hey @zdzichukowalski, I was not able to reproduce this on python 3.11.9 and datasets 3.6.0. The contents of "body" are correctly parsed as a string and no other fields like timestamps are created. Could you try reproducing this in a fresh environment, or posting the complete code where you encountered that stacktrace? (I noticed in the stacktrace you had a bigger program, perhaps there are some side effects)

Hi @zdzichukowalski, thanks for reporting this!

To help investigate this further, could you please share the following:

Exact contents of the data.jsonl file you're using — especially the first few lines that trigger the error.

The full code snippet you used to run load_dataset(), along with any environment setup (if not already shared).

Can you confirm whether the issue persists when running in a clean virtual environment (e.g., with only datasets, pyarrow, and their dependencies)?

If possible, could you try running the same with an explicit features schema, like:

```
from datasets import load_dataset, Features, Value
features = Features({"body": Value("string")})
ds = load_dataset("json", data_files="data.jsonl", split="train", features=features)
```
Also, just to clarify — does the "body" field contain plain string content, or is it sometimes being parsed from multi-line or structured inputs (like embedded JSON or CSV-like text)?

Once we have this info, we can check whether this is a schema inference issue, a PyArrow type coercion bug, or something else.

Ok I can confirm that I also cannot reproduce the error in a clean environment with the minimized version of the dataset that I provided. Same story for the old environment. Nonetheless the bug still happens in the new environment with the full version of the dataset, which I am providing now. Please let me know if now you can reproduce the problem.

Additionally I'm attaching result of the `pip freeze` command.

[datasets-issues.jsonl.zip](https://github.com/user-attachments/files/21081755/datasets-issues.jsonl.zip)
[requirements.txt](https://github.com/user-attachments/files/21081776/requirements.txt)

@ArjunJagdale running with explicit script gives the following stack:
[stack_features_version.txt](https://github.com/user-attachments/files/21082056/stack_features_version.txt)

The problematic `body` field seems to be e.g. content of [this comment](https://github.com/huggingface/datasets/issues/5596#issue-1604919993) from Github in which someone provided a stack trace containing json structure ;) I would say that it is intended to be a plain string. 

To find a part that triggers an error, simply search for the "timestamp[s]" in the dataset. There are few such entries.

I think I provided all the information you asked. 

Oh, and workaround I suggested, that is convert `.jsonl` to `.json` worked for me.

P.S
1. @itsmejul the stack trace I provided is coming from running the two-liner script that I attached. There is no bigger program, although there were some jupiter files alongside the script, which were run in the same env. I am not sure what part of the stack trace suggests that there is something more ;) 

2. Is it possible that on some layer in the python/env/jupiter there is some caching mechanism for files that would give false results for my minimized version of the dataset file? There is of course possibility that I made a mistake and run the script with the wrong file, but I double and triple checked things before creating an issue. Earlier I wrote that "(...) changing the file extension to `.json` or `.txt` avoids the problem". But with the full version this is not true(when I change to `txt`), and minimized version always works. So it looks like that when I changed the extension to e.g. `txt` then a minimized file loaded from the disk and it was parsed correctly, but every time when I changed back to `jsonl` my script must have used an original content of the file - the one before I made a minimization. But this is still all strange because I even removed the fields before and after the body from my minimized `jsonl` and there were some different errors(I mention it in my original post), so I do not get why today I cannot reproduce it in the original env... 



Hi @zdzichukowalski, thanks again for the detailed info and files!

I’ve reviewed the `datasets-issues.jsonl` you shared, and I can now confirm the issue with full clarity:

Some entries in the `"body"` field contain string content that resembles schema definitions — for example:

```
struct<type: string, action: string, datetime: timestamp[s], ...>
```

These strings appear to be copied from GitHub comments or stack traces (e.g., from #5596)

When using the `.jsonl` format, `load_dataset()` relies on row-wise schema inference via PyArrow. If some rows contain real structured fields like `pull_request.merged_at` (a valid timestamp), and others contain schema-like text inside string fields, PyArrow can get confused while unifying the schema — leading to cast errors.

That’s why:

* Using a reduced schema like `features={"body": Value("string")}` fails — because the full table has many more fields.
* Converting the file to `.json` (a list of objects) works — because global schema inference kicks in.
* Filtering the dataset to only the `body` field avoids the issue entirely.

### Suggested Workarounds

* Convert the `.jsonl` file to `.json` to enable global schema inference.
* Or, preprocess the `.jsonl` file to extract only the `"body"` field if that’s all you need.

So in summary should we treat it as a low severity bug in `PyArrow`, in `Datasets` library, or as a proper behavior and do nothing with it?

You are right actually! I’d also categorize this as a low-severity schema inference edge case, mainly stemming from PyArrow, but exposed by how datasets handles .jsonl inputs.

It's not a bug in datasets per se, but confusing when string fields (like body) contain text that resembles schema — e.g., "timestamp[s]".

Maybe @lhoestq — could this be considered as a small feature/improvement?