bugraoz93 commented on PR #61532: URL: https://github.com/apache/airflow/pull/61532#issuecomment-3867027712
> > ks great, thanks! > > This looks like breaking for the public API on the datamodel change. It won't in most of the cases due to str translation of HTTP layer but if someone depends on our datamodels to communicate, then API communication would break. It would be amazing if you can add significant newsfragment for it so it could be descriptive to any type of > > @bugraoz93 What do you mean in regards of public API and data model? The DB Model is for sure not a public API and we usually warn everybody who makes calls and interactions with the DB. > > Rest API only makes now a bit more preceise details about the format of the UUID keys. Do you see this as a breaking change? Because content will not be different. Thanks Jens, good question! This could maybe explain more, so I can see if I missed anything too I haven't meant to do anything with db calls. My comment was purely on bespoke clients or API extensions. Since type is still a `string` in the `schema`, I don't think this will impact most of the users. For example, if they introduced a new endpoint in their environment, or even applications that extend and use Airflow Public API, or some process that depends on our `datamodels` to communicate with the Public API or extend in any way. In that case, `ti.id` is not `str` anymore for those use cases for them while using as `from airflow.api_fastapi.core_api.datamodels.task_instances import TaskInstanceResponse`, they may need to do some level of casting or a change in their type annotations in their code. They should do some degree of change, I assume What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
