proto: deprecate duplicate string fields in requests #3661
Conversation
lnrpc/rpc.proto
Outdated
| Hex-encoded string representing the funding transaction. Deprecated now | ||
| that the REST gateway supports base64 encoding of bytes fields. | ||
| */ | ||
| string funding_txid_str = 2 [json_name = "funding_txid_str", deprecated = true]; |
There was a problem hiding this comment.
This makes the whole oneof redundant. But maybe that removal should be done in a second step?
There was a problem hiding this comment.
I removed the deprecation from this field again. This is the case @Roasbeef mentioned where it might be useful for the users to be able to just pass in the string representation of a TXID that they get from a previous output and don't need to byte-reverse it before feeding it into the RPC/REST call. So the oneof can also remain.
guggero
force-pushed
the
deprecate-rest-string
branch
from
d8032a1 to
203974e
Compare
|
I removed the deprecation from the TXID field. There are only 5 deprecations in this PR now, all of them are duplicates and very likely introduced to work around the bug that is now fixed. |
There was a problem hiding this comment.
I removed the deprecation from this field again. This is the case @Roasbeef mentioned where it might be useful for the users to be able to just pass in the string representation of a TXID that they get from a previous output and don't need to byte-reverse it before feeding it into the RPC/REST call. So the oneof can also remain.
Seems more like an inconsistency with our API then? As long as we accept and return them in the same format, there's no need to keep the string field.
lnrpc/rpc.proto
Outdated
| @@ -94,13 +94,15 @@ service WalletUnlocker { | |||
| message GenSeedRequest { | |||
| /** | |||
| aezeed_passphrase is an optional user provided passphrase that will be used | |||
| to encrypt the generated aezeed cipher seed. | |||
| to encrypt the generated aezeed cipher seed. When using REST, this field | |||
There was a problem hiding this comment.
Nit: there's a double space after the period here and in some other cases below that would be reflected in the API documentation.
There was a problem hiding this comment.
The double space was used in several places so I thought that was a style we wanted to use for some reason. But I removed all of them now.
With this PR we deprecate fields that have been specifically added to to work around a bug in the gRPC/REST gateway that didn't allow bytes fields to be encoded in REST requests. That bug has now been fixed so the fields are no longer required. To make it more clear how bytes fields have to be used in REST, comments have been added to all those fields.
guggero
force-pushed
the
deprecate-rest-string
branch
from
203974e to
7e9c4f0
Compare
|
There are quite a few inconsistencies in the API, especially around the TXIDs. |
Follow-up for #3650.
With this PR we deprecate fields that have been specifically added to
to work around a bug in the gRPC/REST gateway that didn't allow bytes
fields to be encoded in REST requests.
That bug has now been fixed so the fields are no longer required.
To make it more clear how bytes fields have to be used in REST,
comments have been added to all those fields.