[bitreq] Check utf-8 while deserializing JSON body by tankyleo · Pull Request #486 · rust-bitcoin/corepc

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo · 2026-01-28T04:25:03Z

 [bitreq] Check utf-8 while deserializing JSON body
While deserializing, `serde_json::from_slice` validates utf-8 as
needed. So instead of making two passes on the response body, one
to validate utf-8, and another to deserialize the object, we can
let `serde_json::from_slice` check utf-8 as needed during
deserialization.
`Response::json` now returns `Error::SerdeJsonError` instead of
`Error::InvalidUtf8InBody` if invalid utf-8 bytes are found during
deserialization.

and

 [bitreq] Serialize `Request` body into `Vec<u8>`
We avoid creating a `String` only to immediately convert it back to its
inner `Vec<u8>`.
This also mirrors the `serde_json::from_slice` call made when parsing a
`Response` body as JSON.

tankyleo · 2026-01-28T04:27:20Z

This came up while me and @tnull were working on migrating to bitreq in lightningdevkit/vss-client#56

tnull

ACK a3ae780

TheBlueMatt · 2026-01-28T12:30:57Z

 T: serde::de::Deserialize<'a>,
 {
- match serde_json::from_str(self.as_str()?) {
+ match serde_json::from_slice(self.as_bytes()) {


Do we really prefer the serde error over the utf8 error? I'm skeptical the claimed perf difference matters (notably when deserializing a string in the json serde skips utf8 validation if you call from_str whereas has to do it if you call from_slice). I don't have a strong feeling on the error but the commit should explain why we prefer the swap.

Thanks Matt see below, I have expanded the commit message.
I'm skeptical the claimed perf difference matters
The claim is that a reduction in cache misses leads to non-trivial performance gains.
We still do the same amount of work on the data.

While deserializing, `serde_json::from_slice` validates utf-8 as needed. So instead of making two passes on the response body, one to validate utf-8, and another to deserialize the object, we let `serde_json::from_slice` check utf-8 as needed during deserialization. Making a single pass over large response bodies reduces the number of cache misses, and hence decreases the cycles taken to fully deserialize such responses. `Response::json` now returns `Error::SerdeJsonError` instead of `Error::InvalidUtf8InBody` if invalid utf-8 is found during deserialization. For this error case, the `Error::SerdeJsonError` inner type `serde_json::error::Error` is of category `serde_json::error::Category::Syntax`. Other JSON syntax errors are also assigned to this category. We accept this loss of information given the performance gain described above.

We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

TheBlueMatt

Mmm, fair enough.

ACK 2c3bbf2

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

tankyleo requested review from TheBlueMatt and oleonardolima as code owners January 28, 2026 04:25

tnull approved these changes Jan 28, 2026
View reviewed changes

TheBlueMatt reviewed Jan 28, 2026
View reviewed changes

tankyleo added 2 commits January 30, 2026 19:07

[bitreq] Serialize Request body into Vec<u8>
2c3bbf2
We avoid creating a `String` only to immediately convert it back to its inner `Vec<u8>`. This also mirrors the `serde_json::from_slice` call made when parsing a `Response` body as JSON.

tankyleo force-pushed the 26-01-check-utf8-while-flying branch from a3ae780 to 2c3bbf2Compare January 30, 2026 19:08

tankyleo requested a review from TheBlueMatt January 30, 2026 19:15

TheBlueMatt approved these changes Jan 30, 2026
View reviewed changes

tnull merged commit cfba70d into rust-bitcoin:masterJan 30, 2026
31 checks passed

Uh oh!

Conversation

tankyleo commented Jan 28, 2026

Uh oh!

tankyleo commented Jan 28, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

tankyleo commented Jan 28, 2026

Uh oh!

tankyleo commented Jan 28, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

tankyleo commented Jan 28, 2026

Uh oh!

tankyleo commented Jan 28, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

tankyleo commented Jan 28, 2026

Uh oh!

tankyleo commented Jan 28, 2026