Write ChannelIds out as hex in Debug output

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.

[TheBlueMatt]

ChannelIds are almost always referenced as hex, so having debug
output print the raw bytes is somewhat annoying. Instead, we should
dump them as hex the same way we do for Display.

This uses the hex_conservativeimpl_fmt_macros which does all
the work for us, like we use for lightning_types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.62%. Comparing base (eba329c) to head (98d15f2).
Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3306 +/- ##
==========================================
- Coverage 89.63% 89.62% -0.01% 
==========================================
Files 126 126 Lines 102166 102166 Branches 102166 102166 ==========================================
- Hits 91572 91564 -8 - Misses 7869 7878 +9 + Partials 2725 2724 -1 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tnull]

While we're here, can we introduce a UserChannelId type adding the same feature?

[TheBlueMatt]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

[tnull]

Do we want user channel IDs to print as hex? One intended use-case for them is database row IDs, which presumably users don't want to see as hex.

Hm, well, not necessarily as hex, but IMO UserChannelId(340282366920938463463374607431768211455) would already improve readability in logs (and having the type live in LDK makes sense).

[TheBlueMatt]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

[tnull]

I'm not sure I understand how UserChannelId() improves logs as long as the context is clear. eg in debug output you get things like Struct { .., user_channel_id: 123456789, .. }, which gives pretty clear context. If there's some logs that don't have context we should probably add context rather than wrap, IMO.

Alright. Besides the display/debugging preferences, I'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages). FWIW, LDK Node already has such a type, but IMO it would make sense to use it upstream as well. In any case, this seems to be a separate discussion which shouldn't hold up this PR.

[TheBlueMatt]

'd generally prefer to use a dedicated type parallel to ChannelId in the API rather than a u128 (which, for example, doesn't work well on all platforms/languages).

Mmm, yea. I generally dislike the proliferation of newtypes so prefer to only use them sparingly where it really makes sense (eg because we have a million [u8; 32] types flying around), but I admit the lack of support in various languages is a strong argument for doing it here.