FuelLabs
Chargeable Transaction V2
Part of https://github.com/FuelLabs/fuel-vm/issues/955
After trying a few different approaches for the new ChargeableTransactionV2, ended up with just extending the Input type to have an InputV2 variant.
This doesn't give us as much type safety, but the way our code is written it saves a lot of work and it needs coverage for those cases anyway. (This is a good case study for why non-interface trait abstractions should be kept to a minimum and used with care).
This is the initial "tracer-bullet" PR. It's pretty simple with just one test. Follow-up work will add a lot more coverage for more cases and preventing mixing input types etc.
Added new feature to protect the codebase until the feature is fully implemented and tested.
Checklist
- [x] New behavior is reflected in tests
Before requesting review
- [x] I have reviewed the code myself
The feature-flag protection is not extended to all things here, for instance the Input::InputV2 variant isn't covered. I'm not sure how much issue this actually is, but it's already a breaking change as it allows deserializing transactions that weren't valid before. This means we cannot release these changes even when feature-flag protected. I'm not sure if this blocks us from merging into master.
There are a lot of todo!()s left, but I assume these are mostly intentional, and they seem to be feature-flag protected.
The feature-flag protection is not extended to all things here, for instance the Input::InputV2 variant isn't covered. I'm not sure how much issue this actually is, but it's already a breaking change as it allows deserializing transactions that weren't valid before. This means we cannot release these changes even when feature-flag protected. I'm not sure if this blocks us from merging into master.
I think I've corrected a lot of these spots in https://github.com/FuelLabs/fuel-vm/pull/960, so maybe we merge them before merging into `master.
There are a lot of todo!()s left, but I assume these are mostly intentional, and they seem to be feature-flag protected.
Assuming they are all behind the feature flag, then I don't care. If I missed some spots (very possible) then I will fix those.