-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
fix publish fail on prexisting bad record #1775
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
Conversation
tested on four different nodes live on the network, mars, my desktop, my laptop, and one other machine i've had online forever, publishing and resolution works across the board there, even when updating from v0.3.3 to latest on a node that previously had an ipns entry. I want to use something (like nomad) for staging and testing network upgrades for things like this. I'm thinking of having a docker image 'ipfs-bot' that will start ipfs, connect either to the primary network, or just bootstrap to our other test nodes (leaning towards the main network), and then run random commands and sets of operations. |
@whyrusleeping re test network, this is what i want with golang/build. i'm looking more at nomad and it seems tuned much more for stationary things, not for running random, isolated, resource constrained, one-off tasks. it may be that we can use nomad to orchestrate managing the builder processes, but running one-off taksa (builds or tests), the dashboard, viewable logs, etc, don't seem to be covered by nomad. |
I think we're talking about different things here. I want to have a network of long lived nodes, and have the ability to say 'update 20% of our test nodes to this new builds, and have them run a bunch of tasks', or 'wipe half of our test network, bring that many new nodes online, and see what happens' |
} else if err != ds.ErrNotFound { | ||
return err | ||
return 0, err |
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.
this won't work with a node whose local repo is destroyed, but has records published. you'll end up with records at very low seqnos that won't overwrite the others. two options:
- request the record, see what comes back, take the max and go from there
- use the creation timestamp as a seqno (so, two timestamps, one for creation, one for publication)
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.
hrm... okay.
4105a6f
to
17c2995
Compare
dont error out if prexisting record is bad, just grab its sequence number and continue on with the publish. License: MIT Signed-off-by: Jeromy <[email protected]>
17c2995
to
b34d41e
Compare
@jbenet alright. I think weve got this one in the bag. |
LGTM! |
fix publish fail on prexisting bad record
that's a great cat |
dont error out if prexisting record is bad, just grab its sequence number
and continue on with the publish.
License: MIT
Signed-off-by: Jeromy [email protected]