Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.00%. Comparing base (ba3d4ff) to head (1cdce16).
Report is 6 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3332      +/-   ##
==========================================
+ Coverage   89.25%   90.00%   +0.74%     
==========================================
  Files         130      130              
  Lines      106959   111140    +4181     
  Branches   106959   111140    +4181     
==========================================
+ Hits        95464   100029    +4565     
+ Misses       8706     8343     -363     
+ Partials     2789     2768      -21     

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

Discussed briefly offline. This may not be needed if we split ChannelContext to avoid duplicating some fields.

This change request assumes that the whole ChannelContext struct is duplicated, which may not be the best solution. I put this on hold for now (back to draft, description updated).

Not sure if cloning is the best solution. But, regardless, since the channel signer is a Deref can't we just add a Clone trait bound?

There are 4 Mutex fields, used for testing/fuzzing: I placed them under refcounting (`Arc), so they can be cloned.

The only non-cloneable field is the signer. The signer could also be placed under Arc, but I find that unjustified complexity and inefficiency for this infrequent use case.

Still up for discussion, different approaches being discussed, to get rid of per-field cloning:

• change inside Signer so that it is clonable (it is not due to atomic counters)
• in relation with the channel phase refactor Channel phase refactor, wrap channel phase, store wrapped phase in map #3418, possible move signer out of channel context to the channel wrapper, so it doesn't have to be cloned. It would affect methods which uses the signer (to be moved 'out' as well or pass the signer)
• place the signer behind Arc (Arc<Mutex>?) -- not preferred, unnecessary complexity/inefficiency

Rebased

Superseded by #3592 and #3604.