Pydantic validation errors with API responses

[turukawa]

I have just completed a full payments workflow based on @elijah0kello's pull request, #10 on the documentation. I have a number of queries related to the Pydantic models.

1. Mandatory fields not present in response data

Several models (cf OutgoingPayment, IncomingPayment, etc.) have a mandatory updatedAt field. This is not present in responses from interledger-test.dev and causes endless errors.

I don't know if you feel it's needed anywhere? If it is needed, could I replace them all with, e.g.

    updatedAt: Optional[datetime] = Field(
        None, description="The date and time when the incoming payment was updated."
    )

2. Additional fields present in response data and forbidden in the models

Multiple models have model_config that is set to forbid extra fields (cf IlpPaymentMethod, OutgoingPayment)

    model_config = ConfigDict(
        extra="forbid",
    )

Except there are additional fields sent by the identity provider, which also causes errors.

Is there any reason for this setting? If not, can it be removed?

    model_config = ConfigDict()

3. Deeply-nested Pydantic models

I am a little confused by the structure of the Pydantic models. There are a very large number of one-time-use fields that instead are structured as RootModel string fields.

Instead of e.g.

  field_value: str = Field(..., description="Some field value")

We have:

class FieldValue(RootModel[str]):
    root: str = Field(..., description="A string field value")

class DeepFieldValue(RootModel[str]):
    root: FieldValue = Field(..., description="A FieldValue")

class UsefulModel(BaseModel):
    model_config = ConfigDict(
        extra="forbid",
    )
    useful_field: DeepFieldValue = Field(..., description="A DeepFieldValue")

This is really hard to read, and I can't imagine trying to maintain it. Should I have a go at refactoring it?

In any case, I have a working version, so we're definitely getting there. Thanks.

[elijah0kello]

Thank you @turukawa for giving it a test drive. In regards to the recommended fixes, I think it definitely makes sense to have them incorporated into the SDK.

And for the pydantic models, yes I agree they are a bit too deeply nested and complex.

[Tymmmy]

@turukawa would you like me to aprove the PR from ELijah, and then you can refactr=or the complex and nested parts?

[turukawa]

Yes, @Tymmmy, that would be great. Don't treat @elijah0kello's PR as a final working library, but it is a very critical step along the way.

[Tymmmy]

Thanks @turukawa , for sure we will not treat this a working library, it is still a work in progress, and on that note, I will merge the PR, and please proceed to refactor things when you have time :) .
Much apreciated.