Smart protocol: Support force push/pull in

[sergiimk]

Describe the bug

Force push/pull in Smart Protocol are currently not working which is major speedbump when testing things with live kamu-node.

Steps To Reproduce

1. Hard-compact remote dataset and try pulling it from the node
2. Hard-compact local dataset and try pushing it to the node

Current Behavior

Tool returns obscure errors

Expected Behavior

Force push/pull works just like in the Simple Transfer Protocol

kamu system info

appVersion: 0.191.4
buildTimestamp: 2024-07-23T18:24:43.432679860Z
gitDescribe: v0.191.1-7-g0fc45cd4
gitSha: 0fc45cd453f2a15a521fea5763fdd0b9f8c44af6
gitCommitDate: 2024-07-23
gitBranch: master
rustcSemver: 1.81.0-nightly
rustcChannel: nightly
rustcHostTriple: x86_64-unknown-linux-gnu
rustcCommitSha: 8337ba9189de188e2ed417018af2bf17a57d51ac
cargoTargetTriple: x86_64-unknown-linux-gnu
cargoFeatures: default,rust_embed,web_ui
cargoOptLevel: '0'

Logs

No response

Anything else?

Force pull-push should also correctly react when the identity of a dataset changes, e.g. this scenario:

1. create local dataset gps
2. push it to the node
3. re-create local dataset so that it gets new DatasetID
4. push it to the node with --force flag

test the mirror pulling scenario as well

[rmn-boiko]

The command now works without any errors, but there is another tricky moment.
When running the same scenario we do not update summary information, and the confusion is that in the first block there is new DatasetID which was force pushed but in summary where is still old one. @sergiimk @zaychenko-sergei Should we update the summary info as well?

[sergiimk]

in the first block there is new DatasetID which was force pushed

Hmm, interesting case. So we have two situations:

• "Normal" force push where local and remote datasets have at least one block in common. In this case the push process should:
  • determine the last common ancestor block
  • push all missing blocks and objects to remote
  • overwrite the head
• "Replace" force push where a completely different dataset with different ID is being pushed under the same alias

For "replace" I see two options:

• Return an error saying that two datasets are unrelated
• Create a new dataset from local and either:
  • Delete the remote dataset
  • Or leave the remote dataset as-is and only take away its name

I like the last option, but we'd need to decide what name to give to the old dataset... Perhaps we could rename it to did.odf.feedab...a123 and let the user rename or delete it if they want to?

[sergiimk]

In either case I think summary is only a problem with repo structure that stores datasets by name (like CLI local workspace). It shouldn't be an issue in repos that store datasets by ID. Renaming solution should work for CLI in the short term, but I also hope #342 will solve this once and for all soon.