Inconsistencey of fee_rate types

[Arshia-r-m]

I noticed that in EstimateFeeRespons the fee_rate field is f64 , the fee rate is but in SendBtcRequest and all other models using this field is u64.

Also in the openapi.yaml, their type is number , where in the exact struct (SendBtcRequest), the amount is also u64 and it's type in the openapi is integer instead of number.
Is this expected?If not I'll open a PR resolving them with your comments.

This cause trouble when using openapi code generator.

[zoedberg]

This is expected. The fee estimation is retrieved from the explorers, which return estimation in f64. The fee_rate in the SendBtcRequest is instead the fee that BDK requires, which since v1.0.0 wants an integer fee. What trouble is this causing?

[Arshia-r-m]

The problem derives from the openapi.yaml, if we can just replace the number with integer would resolve my problem and I think it doesn't break anything

[zoedberg]

I'm not against the change but before we proceed I would like to understand what problem is this causing

[Arshia-r-m]

We are using openapi model generators to generate the request/response models from open-api.yaml file, with the field marked as number, the generator treats it as any json number, where node expects only u64(int). Correct me if I'm wrong please.

[Arshia-r-m]

I would also like to propose adding the required field in the OpenAPI, to indicate the required fields and match it more closely to what the endpoints expect. Let me know what you think about this, please.

[zoedberg]

the generator treats it as any json number, where node expects only u64(int). Correct me if I'm wrong please.

I don't know which generator you're using and I thought u64 didn't exist in node.js, so it's hard to say if you're right

I would also like to propose adding the required field in the OpenAPI

If you propose a PR where you add the required field to all the spec objects (where necessary of course) then I'm happy with this change. The same is for the integer/number question, I would appreciate a lot a PR that fixes all the fields by making sure we always use integer when in Rust there's an unsigned number.

[Arshia-r-m]

I don't know which generator you're using and I thought u64 didn't exist in node.js, so it's hard to say if you're right

We are using datamodel-code-generator for python, which treats the number as float.

If you propose a PR where you add the required field to all the spec objects (where necessary of course) then I'm happy with this change. The same is for the integer/number question, I would appreciate a lot a PR that fixes all the fields by making sure we always use integer when in Rust there's an unsigned number.

Do you prefer two seprate PRs or a single one with both changed?

[zoedberg]

Do you prefer two seprate PRs or a single one with both changed?

A single PR would be great, thanks

[zoedberg]

Done in #104