Skip to content

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

Merged
merged 1 commit into from
Oct 2, 2015
Merged

Conversation

whyrusleeping
Copy link
Member

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]

@jbenet jbenet added the status/in-progress In progress label Oct 1, 2015
@whyrusleeping
Copy link
Member Author

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.

@jbenet
Copy link
Member

jbenet commented Oct 2, 2015

@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.

@whyrusleeping
Copy link
Member Author

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
Copy link
Member

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hrm... okay.

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]>
@whyrusleeping
Copy link
Member Author

@jbenet alright. I think weve got this one in the bag.

@whyrusleeping
Copy link
Member Author

like, more in the bag than this cat:
image

@jbenet
Copy link
Member

jbenet commented Oct 2, 2015

LGTM!

jbenet added a commit that referenced this pull request Oct 2, 2015
fix publish fail on prexisting bad record
@jbenet jbenet merged commit 7e69146 into master Oct 2, 2015
@jbenet jbenet removed the status/in-progress In progress label Oct 2, 2015
@jbenet jbenet deleted the fix/ipns-old-record branch October 2, 2015 22:08
@jbenet
Copy link
Member

jbenet commented Oct 2, 2015

that's a great cat

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants