What's the issue?

It is possible to initialize a Config object with an argument which is not an attribute of the Config class. This is a foot-gun and should be disallowed by default in Config subclasses.

This behavior is the default of Pydantic BaseModels, requiring users to specify model_config = {"extra": "forbid"} as part of the BaseModel in order to force failure when extra attributes are provided. I suspect this is due to the fact that BaseModels are heavily used in parsing json, where the user may want to ignore extra attributes that are not in the BaseModel without failing.

The use-case for Config objects is quite different than BaseModels in that it defines the allowed configuration interface for an operation, and should only really ever be used with valid configuration dicts. Allowing extra attributes can cause hard-to-spot bugs when Config attributes are updated and manual instantiations of Config objects are not updated in tandem. This could especially be a problem in cases where a Config class is defined in a library the user doesn't control when maintainers update the Config class interface to change or remove attributes. If the fields of the Config class have defaults, users may not know that their Config instantiations are now out-of-date and may not reflect the values they were previously passing.

As a user I can prevent this by creating a Config subclass like this:

class MyConfig(Config):
  model_config = {"extra": "forbid"}

and then use that as my base class for all Config objects. However, this can be difficult to enforce in a large codebase or one distributed across many repos. It would be better if it was the default.

I get that this would likely be considered a breaking change so it may need to be considered carefully. One idea to help mitigate this could be to introduce a StrictConfig class in the short-term that forbids extra attributes, with a plan to eventually update the Config class to forbid extra attributes in a minor version update.

What did you expect to happen?

As a user I would expect if I instantiate a Config object with attributes that don't exist in the Config interface that the instantiation would throw some kind of validation exception.

How to reproduce?

from dagster import Config
from pydantic import Field

class MyConfig(Config):
  a_config: str = Field(default="a_value")

c = MyConfig(a_conf = "a_different_value") # This passes, but `a_conf` just gets ignored

if __name__ == "__main__":
  print(c) 

Dagster version

1.11.4

Deployment type

None

Deployment details

No response

Additional information

No response

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization.