admin openapi spec needs bigger integers in places #476

New issue

Closed

opened 2023-01-13 00:48:31 +00:00 by fivebats · 3 comments

fivebats commented

2023-01-13 00:48:31 +00:00

Contributor

I am using the golang SDK and I have noticed that large numbers are not being marshalled correctly.

A runtime example: error from GetBucketUsage json: cannot unmarshal number 510365619034 into Go struct field BucketInfo.bytes

This appears to be due to the SDK generator creating an int field where an int64 field type is necessary.

I believe the generator will use int64 if the specification file includes a format property set to int64 where the data type is integer.

The openapi spec file I referenced was garage-admin-v0.yml.

I would be happy to edit that file and make a pull request if this is the source of truth for the API tools. (In other words I am not sure whether or not this file is generated.)

So in any case I believe where the sizes can be large the API specification should include format int64 in the spec file so the generated SDK will use int64.

I am using the golang SDK and I have noticed that large numbers are not being marshalled correctly. A runtime example: `error from GetBucketUsage json: cannot unmarshal number 510365619034 into Go struct field BucketInfo.bytes` This appears to be due to the SDK generator creating an int field where an int64 field type is necessary. I believe the generator will use int64 if the specification file includes a format property set to `int64` where the data type is `integer`. The openapi spec file I referenced was [garage-admin-v0.yml](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/branch/main/doc/api/garage-admin-v0.yml). I would be happy to edit that file and make a pull request if this is the source of truth for the API tools. (In other words I am not sure whether or not this file is generated.) So in any case I believe where the sizes can be large the API specification should include format int64 in the spec file so the generated SDK will use int64.

lx commented

2023-01-13 10:46:39 +00:00

Owner

Afaik garage-admin-v0.yml is the source of truth, but we need confirmation from @quentin

Afaik `garage-admin-v0.yml` is the source of truth, but we need confirmation from @quentin

quentin commented

2023-01-14 17:05:42 +00:00

Owner

Indeed the source of truth for the API is the file you identified in this repository: garage-admin-v0.yml. In a general manner, we try to keep the source of truths for Garage in this repository while keeping "children" projects outside (like the website or the SDKs).

Once this file will be patched and merged on Garage's main branch, the next step will be to update the garage-sdk/garage-admin-sdk-generator repository. In this repository, Garage is included as a submodule, submodule I will update to fetch your bug fix. Then I will regenerate the 3 SDKs from here, commit and push the modification, so that both the Python, JS, and Golang SDK benefit from your patch AND stay in sync.

So just ping me when your PR is ready, I will udpdate the SDKs ASAP after that.

Indeed the source of truth for the API is the file you identified in this repository: [garage-admin-v0.yml](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/branch/main/doc/api/garage-admin-v0.yml). In a general manner, we try to keep the source of truths for Garage in this repository while keeping "children" projects outside (like the website or the SDKs). Once this file will be patched and merged on Garage's main branch, the next step will be to update the [garage-sdk/garage-admin-sdk-generator](https://git.deuxfleurs.fr/garage-sdk/garage-admin-sdk-generator) repository. In this repository, Garage is included as a submodule, submodule I will update to fetch your bug fix. Then I will regenerate the 3 SDKs from here, commit and push the modification, so that both the Python, JS, and Golang SDK benefit from your patch AND stay in sync. So just ping me when your PR is ready, I will udpdate the SDKs ASAP after that.