-
Notifications
You must be signed in to change notification settings - Fork 209
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
Add E2E tests for contract termination #899
Conversation
Codecov Report
@@ Coverage Diff @@
## main #899 +/- ##
==========================================
- Coverage 99.98% 99.97% -0.02%
==========================================
Files 297 298 +1
Lines 19400 19463 +63
==========================================
+ Hits 19397 19458 +61
- Misses 3 4 +1
- Partials 0 1 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. |
Factored some of the general enhancements out to #904 as a pre-req before adding the new test here. |
Further, honing of this test has revealed that the migration feature is still a bit broken. Moving back to draft state while addressing the remaining issues. |
Fixed up the test so that it passes now, so I'm opening this back up for review. I think there may still be work to do to reliably terminate the ff_system namespace though. |
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
While V2 -> V2 is also valuable, this is the more complex flow and therefore the most valuable to test. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
POST to /spi/reset will perform a soft restart of everything, including reloading the config from disk. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Ensure the multiparty contract is configured early enough for the network version to be inspected during namespace init. Initialize ff_system if ANY namespace uses multiparty V1 (not just the default namespace). Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Allows callback handlers to wait on event processing to finish, if desired. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Do not attempt to stop the ff_system orchestrator - it's actually possible that there may be unaggregated pins prior to the "terminate" event. Therefore, we must continue listening indefinitely even if the handler is likely to be idle. Also added some TODOs for next steps. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Trying to fix the merge conflicts + update tests got a bit gnarly. Going to fix the tests in this branch, make the |
Signed-off-by: Alex Shorsher <alex.shorsher@kaleido.io>
tests updated, pulling |
Signed-off-by: Alex Shorsher <alex.shorsher@kaleido.io>
Signed-off-by: Alex Shorsher <alex.shorsher@kaleido.io>
Currently investigating the contract migration test and why firefly does not seem to pick up new namespaces after a reset. |
Signed-off-by: Alex Shorsher <alex.shorsher@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Also remove duplicate caching of network version. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
This is now ready for review again. Concluded that the ff_system namespace actually can never be "stopped". Once it exists, we have to keep the listener around forever. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
…ates If a subscription was created with a valid namespace name, and a V1 BatchPin event is received on that subsscription with a different namespace name embedded, simply drop it at the plugin layer. This will avoid passing an extra de-duplication burden up to the event managers. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Because ff_system is global, the contract instance is global. The address can never change, and a second V1 contract can never be used. Adjust the core logic to enforce this. This also means splitting the E2E suite, as a V2->V2 migration is simple to test over and over, but a V1->V2 migration can only be done once per stack. This special test will have to be run infrequently under controlled circumstances. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
This is already handled by namespace manager, not orchestrator. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Pass around a pointer to orchestrator and any children, but retain a single copy of the namespace owned by namespace manager. Also use pointers for the contract information to avoid unnecessary copies. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Part of FIR-12
Depends on hyperledger/firefly-cli#197In a chain with #904Add a new E2E test which dynamically:
There are variations of this test for both V1->V2 contract migrations and V2->V2. Notably, the V1->V2 migration can only be performed once per stack, so it is not part of the main suites. We may need to add a dedicated nightly job for this test.
This PR also includes loads of fixes for things exposed by the E2E tests, including major changes to how the legacy ff_system namespace is managed. There can now only be one multiparty V1 contract EVER used in the history of a FireFly node, and attempting to configure any namespace with a different V1 contract is an error. The ff_system orchestrator will be initialized with that V1 config (if any is found) and will live forever (walking back some of the changes from #884), because we can never be fully sure when all pins from ff_system have been aggregated.