Name publish error: can't replace a newer value with an older value

rklaehn · September 13, 2018, 9:40am

Yesterday I have encountered a key that I am unable to publish to. Any attempt to publish to the key produces the following error message:

$ ipfs name publish --key=thebrokenkey /ipfs/QmQ579LpiPt84mL5CzcQN51eymu4xAAxpSP9m89RUHVHNG
Error: can't replace a newer value with an older value

I dug in to the code a bit and found the place where this error string is being produced here

github.com

libp2p/go-libp2p-kad-dht/blob/master/routing.go#L68


	}


	// Check if we have an old value that's not the same as the new one.
	if old != nil && !bytes.Equal(old.GetValue(), value) {
		// Check to see if the new one is better.
		i, err := dht.Validator.Select(key, [][]byte{value, old.GetValue()})
		if err != nil {
			return err
		}
		if i != 0 {
			return fmt.Errorf("can't replace a newer value with an older value")
		}
	}


	rec := record.MakePutRecord(key, value)
	rec.TimeReceived = u.FormatRFC3339(time.Now())
	err = dht.putLocal(key, rec)
	if err != nil {
		return err
	}

But not being a go programmer and not having a go IDE, I was unable to figure out what produces the i != 0. Some kind of validator that compares the old value to the new value. But shouldn’t I be able to publish arbitrary values in IPNS, as long as they are proper CIDs?

Any idea what caused this issue? It forced us to replace the key with a new one, which was quite painful since it was used in multiple places. And I would really like to understand this.

IPFS version was 0.4.17, on Linux amd64.

p.s. I don’t think this is related in any way, but this is a private swarm.

wngr · December 4, 2018, 10:44am

This is starting to happening more frequently now for us.

stebalien · December 4, 2018, 5:41pm

This looks related to

That is, it looks like there’s a newer copy on the network from another node.

rklaehn · December 5, 2018, 11:04am

This happened on a fresh private swarm, so there is zero chance that there’s a newer copy on the network from another node.

Besides, if I publish and see a “newer” record (I suppose in terms of sequence number), should I then not just publish with sequence number + 1 instead of giving up?

I mean, if I have the keypair including private key I should be able to publish no matter what, right?

stebalien · December 5, 2018, 5:23pm

Has the node you’re publishing from ever resolved this IPNS address? It looks like:

This node published the IPNS record.
Some other node published using the same key.
This node resolved that IPNS record.

That means our local record in our local DHT is newer than our “last published” record.

We could do that but:

That would require an additional DHT lookup for every publish (to check for an old copy).
Isn’t guaranteed to work regardless. It simply may not find the latest value.

Regardless, we do need to support migrating keys. This might require some kind of resolve-then-publish flag.

rklaehn · December 5, 2018, 6:58pm

This is a private swarm, and there is only one node on which we publish via IPNS. So this is not possible.

Is there any way to get this “unstuck” without having to generate a new keypair?

A feature being a bit slower is preferable to it not working at all. Currently the situation is that we publish to a IPNS keypair and occasionally get into the situation where we can not publish to it anymore, no matter what we do. The only thing that works is generating a new keypair, which is extremely disruptive. We are about to give up on the PKI part of IPNS and just do DNS… But that is a problem because DNS TXT record lookup does not work on android.

Well, it is understood that this can only ever be best effort because of partitions. E.g. you have sequence number 10 and somewhere in another partition there is a sequence number 20. There is no way for you to find out, but once the partition heals the 20 will win I guess…

stebalien · December 5, 2018, 7:48pm

If you’re only publishing from one node, this should not happen (with or without the network request). In that case, this is a bug.

Does this happen every time? The record in the DHT should expire after 24 hours after which this should start working again. If it keeps working and then not working on the same node, something is very wrong (it shouldn’t fail in the first place but this’ll help track down where the problem is).

Are you clearing/resetting the datastore somehow?

rklaehn · December 5, 2018, 7:56pm

In all cases where we had this, we are publishing from one node. Basically it is a node that is used from travis ci to publish new stuff in a private swarm. There are plenty of other devices in the private swarm, but none of them are set up to publish. They don’t even have keys.

This happens rarely, but once it happens it happens on every publish attempt for a keypair. Unfortunately in all situations where we had this we had to resort to changing to a new keypair and then updating the ipns links in various places, so we don’t know whether it would work again after 24h.

No. Should we? How would we do this?

stebalien · January 3, 2019, 11:52pm

No. I was just wondering if you were somehow reusing the key/id after deleting the local datastore.

anacrolix · January 7, 2019, 12:14am

I’m also getting this. What can I provide to diagnose it?

Topic		Replies	Views
Ipfs name failing to resolve ipns	9	2333	November 29, 2017
Unable to resolve IPNS name published from go-ipfs	14	1474	January 29, 2023
IPNS publishing after generating a key Help	10	5498	March 28, 2017
Dealing with "rapidly mutating" content on IPNS IPFS	9	455	January 15, 2022
Ipfs name publish does not publish to peerID Help ipns	2	404	November 23, 2020

Name publish error: can't replace a newer value with an older value

Related Topics