Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose onion_message items directly rather than via re-exports #2821

Merged

Conversation

TheBlueMatt
Copy link
Collaborator

When we originally added the onion_message module, there weren't a lot of public items in it, and it didn't make a lot of sense to export the whole sub-module structure publicly. So, instead, we exported the public items via re-exports directly in the onion_message top-level module. However, as time went on, more and more things entered the module, which left the top-level module rather cluttered.

Worse, in 0.0.119, we exposed
onion_message::messenger::SendSuccess via the return type of send_message, but forgot to re-export the enum itself, making it impossible to actually use from external code.

Here we address both issues and simply replace the re-export with the underlying sub-module structure.

@TheBlueMatt TheBlueMatt added this to the 0.0.120 milestone Jan 10, 2024
@TheBlueMatt TheBlueMatt force-pushed the 2024-01-om-direct-export branch 2 times, most recently from 81b4fe3 to eec1923 Compare January 10, 2024 18:44
@codecov-commenter
Copy link

codecov-commenter commented Jan 10, 2024

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (f352d03) 88.43% compared to head (ab66143) 89.27%.
Report is 15 commits behind head on main.

Files Patch % Lines
lightning/src/ln/msgs.rs 0.00% 2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2821      +/-   ##
==========================================
+ Coverage   88.43%   89.27%   +0.84%     
==========================================
  Files         114      114              
  Lines       91957    96071    +4114     
  Branches    91957    96071    +4114     
==========================================
+ Hits        81326    85772    +4446     
+ Misses       8115     7870     -245     
+ Partials     2516     2429      -87     

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

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fuzz code needs updating, too.

lightning/src/onion_message/messenger.rs Outdated Show resolved Hide resolved
lightning/src/onion_message/functional_tests.rs Outdated Show resolved Hide resolved
lightning/src/ln/peer_handler.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending CI

When we originally added the `onion_message` module, there weren't
a lot of public items in it, and it didn't make a lot of sense to
export the whole sub-module structure publicly. So, instead, we
exported the public items via re-exports directly in the
`onion_message` top-level module. However, as time went on, more
and more things entered the module, which left the top-level module
rather cluttered.

Worse, in 0.0.119, we exposed
`onion_message::messenger::SendSuccess` via the return type of
`send_message`, but forgot to re-export the enum itself, making
it impossible to actually use from external code.

Here we address both issues and simply replace the re-export with
the underlying sub-module structure.
@TheBlueMatt
Copy link
Collaborator Author

Squashed without changes.

@valentinewallace valentinewallace merged commit 9d803a9 into lightningdevkit:main Jan 11, 2024
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants