Inconsistent model_dump behavior with dataclasses and field(init=False)

[treykeown]

Initial Checks

• I confirm that I'm using Pydantic V2

Description

Models will only dump correctly if a field with init=False uses default_factory.

Example Code

import uuid
from pydantic import RootModel
from pydantic.dataclasses import dataclass
from dataclasses import field

@dataclass
class Works:
    id: str = field(init=False, default_factory=lambda: str(uuid.uuid4()))

@dataclass
class DoesntWork1:
    id: str = field(init=False, default="DEFAULT_ID")

@dataclass
class DoesntWork2:
    id: str = field(init=False)

    def __post_init__(self):
        self.id = str(uuid.uuid4())

w = Works()
dw1 = DoesntWork1()
dw2 = DoesntWork2()

print(RootModel[Works](w).model_dump_json())
print(RootModel[DoesntWork1](dw1).model_dump_json())
print(RootModel[DoesntWork2](dw2).model_dump_json())

# Result:
# {"id":"0d984922-443f-4b0d-999e-e91185791ef2"}
# {}
# {}

Python, Pydantic & OS Version

pydantic version: 2.4.2
        pydantic-core version: 2.10.1
          pydantic-core build: profile=release pgo=false
                 install path: .../.venv/lib/python3.12/site-packages/pydantic
               python version: 3.12.0 (main, Oct  2 2023, 22:40:56) [Clang 15.0.0 (clang-1500.0.40.1)]
                     platform: macOS-13.6-arm64-arm-64bit
             related packages: mypy-1.6.1 typing_extensions-4.8.0 fastapi-0.104.0

[treykeown]

@PrettyWood could this be somehow related to #7821 ?

[PrettyWood]

No nothing to do with that
It comes from https://github.com/pydantic/pydantic/blob/main/pydantic/_internal/_fields.py#L251
I reckon #6616 introduced a regression on that
because we now have

@dataclass
class A:
    id: str = field(init=False, default_factory=lambda: str(uuid.uuid4()))

@dataclass
class B:
    id: str = field(init=False, default="DEFAULT_ID")

print(A.__pydantic_fields__)
print(B.__pydantic_fields__) 
# {'id': FieldInfo(annotation=str, required=False, default_factory=<lambda>, init_var=False, kw_only=False)}
# {}

[hramezani]

Thanks @treykeown for reporting this and Thanks @PrettyWood for checking.

I've created a PR to fix the case that default exists(DoesntWork1).

Not sure what should we do in the case with __post_init__(DoesntWork2)

[PrettyWood]

AFAIK there is no easy (and clean) way to tackle __post_init__ so I would have done like you and just ignore this case (this is an edge case)