-
Notifications
You must be signed in to change notification settings - Fork 47
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
CodecToStr and Codecs in v0.3.1 could cause data corruption #144
Comments
Ah hum ... mb Ill revert, open pr for 0.3.2 and fix Kubo's dep |
Well, as I said in #142, the main break is experienced via So, in hindsight, I still think we made the wrong call in #137 and should have gone through a longer deprecation cycle, using the deprecation tools afforded by Go—which aren't awesome, but they exist. More discussion in #142 would have been nice to work through this a bit further. |
Just to be clear (and reiterate #137), both
In my mind, this is not something we can "silently fix" like you did in #142. My position is:
Digression about work in Q1 and potential shortcuts: I am deeply aware how core go-cid is, and how painful bubbling this up is 😿 Kubo team went over this in IPFS in Q1: had to open multiple surgical PRs to fix this mess in Kubo 0.13.0 and go-libp2p, and change many commands in a way that does not silently break existing users (see summary of BREAKING CHANGES in release notes). Note the strategy around #137 was to replace use of Initially, we only bumped go-cid to v0.2.0 in Kubo to force refactor of impacted code paths and redesign of end user commands. Sure, it is a lot of tedious work, but the end result in Kubo 0.13.0 avoided exactly the type of silent data corruption described in my comment at the top (and briefly re-introduced in v0.3.1). This was done months ago. Since then, unrelated refactors of go-libp2p landed (such as repo consolidation), and now you have even more technical debt to pay off. You could re-introduce I did not go that route because it felt like dealing with the fallout will be more work than doing things properly and refactoring away from go-cid. |
v0.2.0 we made a conscious decision to make a breaking change to FORCE people to refactor their code, and not be surprised by code changes. Rationale in #137.
In golang major bump is essentially a different package – bumping major does not help people who are already using INVALID mappings. That is why we did it in v0.2.
Recently merged PR #142 removed that safety and could cause unexpected code change if someone updates from v1.0 to v3.0. IIUC we now have this:
cbor
string and expected it to point at0x71
(dag-cbor)?0x51
(cbor)protobuf
string and expected it to point at0x70
(dag-pb)0x50
(protobuf)Upgrading v0.1.x to v0.3.1 can now produce DAGs with different codec and get NO warning about this BREAKING CHANGE.
@Jorropo @rvagg If you reallly want to keep CodecToStr and Codecs, you should make sure they return hard error when someone tries to use them for impacted mappings above. Third-party apps use this library. People don't read release notes. Silent data corruption is not acceptable.
The text was updated successfully, but these errors were encountered: