Fix: filter on crn list & port-forwarding #239
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix: #236
and fix an issue where crn wouldn't get fetch on the crn list due to filter
Also include the fix from this other PR spotted by @RezaRahemtola (#236):
When deleting an instance, the behavior for the
ports-forwarding
aggregate is different between the CLI and the UI:null
(example: https://explorer.aleph.cloud/address/ETH/0x238224C744F4b90b4494516e074D2676ECfC6803/message/AGGREGATE/6bc45c2746f289e8fcf12fd44a0b41eae4c57ba408174cfaa63dda3ca002e2bb)The problem is that the types in the SDK (and thus in the CLI) don't expect an item hash in the
ports-forwarding
aggregate to be null (as you can see, I just added the possibility in this PR).This means that if a user deletes an instance in the UI, then the CLI won't function properly anymore, as it will throw Pydantic parsing errors when fetching the ports, for example when deleting an instance:

Unfortunately the fix is probably not as simple as adding this line: