bug: ant register edit / ant register get not working

[markwylde]

I'm trying to use registers to maintain a mutable reference to my game files, but I'm encountering some unexpected behavior with register updates.

I've raised this on the forums too:
https://forum.autonomi.community/t/understanding-registers/41208/1

What I'm trying to do

Create a register that can point to different versions of my game file, allowing me to update which version players should download.

Steps to reproduce

1. Create a register:

ant register create autonomi-blocks-game testing

2. Verify initial value:

ant register get --name autonomi-blocks-game
# Shows value: [testing]

3. Update the register:

ant register edit --name autonomi-blocks-game "edit-test"
# Shows success message

4. Read the register again:

ant register get --name autonomi-blocks-game
# Still shows original value: [testing]

Expected behavior

After updating the register, reading it should show the new value ("edit-test").

Actual behavior

The register appears to retain its original value ("testing") even after a seemingly successful update operation.

Additional context

The CLI reports success on the update operation and even shows a transaction cost, but the change doesn't seem to persist.

Questions

Is this expected? Am I missing something in how registers should be updated, or is this possibly a bug in how updates are being processed?

[markwylde]

I implemented a ant register history command which allows me to see the history of a register entry.

markwylde@Marks-MacBook-Pro autonomi % ./target/release/ant register history --name markwylde3

🔗 Connected to the Network                                                                                       Getting register history with name: markwylde3
✅ Register history found at: markwylde3
History of values:
[hello]
[&��AF�5��C����^t��������53��D]
markwylde@Marks-MacBook-Pro autonomi % ./target/release/ant register get --name markwylde3

🔗 Connected to the Network                                                                                       Getting register with name: markwylde3
✅ Register found at: markwylde3
With value: [hello]

So I think this shows that ant register get only gets the first change?

[grumbach]

Hi @markwylde, thanks for your contributions! Although I did not manage to reproduce your issue on a local testnet, I did manage to reproduce it in production. After some digging I've confirmed the underlying Pointer was not referencing to the latest head (latest register value) which explains why an old value can show up on get.

Registers keep track of their latest versions through a Pointer which is a mutable data type which allows for free updates (but no history). The reason the pointer sometimes doesn't point to the latest register value is that the newest version of the pointer didn't have enough time to be replicated through the network and unfortunately some nodes still hold the old pointer. Although we ensure eventual consistency, meaning everyone will be informed eventually and will hold the newest pointer, this process can take time depending on node and network performance.

The register I had the issue with was healed after some time and some retries: you can fetch it here to try:
a790f11235ba6983a435ff8de9fe2406f5a80ed264bc70a9dd37b3b5a57468c57d9d85bb5b001438adc279da799aa4a4
It indeed returns the latest value when you get and shows matching history (thanks for your awesome PR btw).

Did you retry after a while? You might encounter the corrupt head pointer error, which is okay as it is the case, but retrying should fix it, and time should make the fix visible (need time for pointer update to replicate).

We are working on improving Pointer update speed, which hopefully will reduce the chance of having issues like the above down the line. I understand that until then, depending on network conditions, it results in a poor register experience, we will do our best to improve that over time and greatly appreciate your input!

Closing this one for now, but feel free to re-open it if your issue persists even after retries and time (replication). If so, please include your register address so we can dig more into it (you can get the address with ant register list).

[markwylde]

Thanks for investigating @grumbach and for the great explanation.

It's strange, because I did markwylde3 several days ago and it's still showing the original value.

> markwylde in autonomi % ./target/release/ant register history --name markwylde3
🔗 Connected to the Network                                                                                       Getting register history with name: markwylde3
✅ Register history found at: markwylde3
History of values:
[hello]
[&��AF�5��C����^t��������53��D]
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register get --name markwylde3
🔗 Connected to the Network                                                                                       Getting register with name: markwylde3
✅ Register found at: markwylde3
With value: [hello]
-------------------------------------------------------------

Sorry that one from a few days ago is a little unclear. I've made a new one an hour ago markwylde5 with an initial value of first and an edit of second.

> markwylde in autonomi % ./target/release/ant register history --name markwylde5
Logging to directory: "/Users/markwylde/Library/Application Support/autonomi/client/logs/log_2025-02-17_08-06-48"
🔗 Connected to the Network
Getting register history with name: markwylde5
✅ Register history found at: markwylde5
History of values:
[first]
[second]
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register get --name markwylde5
Logging to directory: "/Users/markwylde/Library/Application Support/autonomi/client/logs/log_2025-02-17_08-07-55"
🔗 Connected to the Network                                                                                       Getting register with name: markwylde5
✅ Register found at: markwylde5
With value: [first]

It's still showing the first value.

I'll try it again tonight to see if it eventually updates.

I do think you're right as if I try and update it a third time, I get:

> markwylde in autonomi % ./target/release/ant register edit --name markwylde5 third
🔗 Connected to the Network                                                                                       Enter password to decrypt wallet:
Attempting to update register at markwylde5 with new value: third
Error:
   0: Failed to update register at address: markwylde5
   1: Corrupt register: Pointer is apparently not at head, attempting to heal the register by updating it to point to the next entry at GraphEntryAddress(25a6d3), please retry the operation

Location:
   ant-cli/src/commands/register.rs:140

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
-------------------------------------------------------------

How long would you expect it to take to sync? Could it be longer than a day?

[happybeing]

@grumbach I think this issue should remain open until pointers update within say <1s and the behaviour should be noted in Pointer and Register docs as it is a serious bug/litation.

Nice catch @markwylde. I haven't noticed this on local, and have not used the live network yet.

It's similar to problems we had with the old Register imp going back many months.

[markwylde]

Thanks both!

I just tried again, and it's still not synced (7 hours later)

> markwylde in autonomi % ./target/release/ant register list
Retrieving local user data...
✅ You have 3 register(s):
markwylde5: 8266f4664e49b4f0d59e952ea7be0618fa8170b8122e7ba4488cb6841c446fbdc02414a1e5bffda063cd867b136bcd78
markwylde4: a84d4ee56bef626faaab864244c04d09919aa7fff5fd1183b49b14437acd334702b86c81b8cefdcff06b1af6a81a8c4e
markwylde3: 9260f5777b4c2ad1d127930ff195babfc0ac85f00d048b43453cfe412b9c1dd66d78bb55e87ea4330aea6464990bbad1
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register get --name markwylde5
🔗 Connected to the Network                                                                                       Getting register with name: markwylde5
✅ Register found at: markwylde5
With value: [first]
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register get 8266f4664e49b4f0d59e952ea7be0618fa8170b8122e7ba4488cb6841c446fbdc02414a1e5bffda063cd867b136bcd78
🔗 Connected to the Network                                                                                       Getting register at address: 8266f4664e49b4f0d59e952ea7be0618fa8170b8122e7ba4488cb6841c446fbdc02414a1e5bffda063cd867b136bcd78
✅ Register found at: 8266f4664e49b4f0d59e952ea7be0618fa8170b8122e7ba4488cb6841c446fbdc02414a1e5bffda063cd867b136bcd78
With value: [first]
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register edit --name markwylde5 third
🔗 Connected to the Network                                                                                       Enter password to decrypt wallet:
Attempting to update register at markwylde5 with new value: third
Error:
   0: Failed to update register at address: markwylde5
   1: Corrupt register: Pointer is apparently not at head, attempting to heal the register by updating it to point to the next entry at GraphEntryAddress(25a6d3), please retry the operation

Location:
   ant-cli/src/commands/register.rs:140

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
-------------------------------------------------------------
> markwylde in autonomi %

[happybeing]

As a follow up:

I think we can assume there will always be a delay or the possibility of a delay, and for different gets of a pointer to return different values. I saw this with the earlier register implementation and think it is just a property of not trying for true concensus.

So I propose:

• we document that Pointer behaviour as expected
• we treat the Register (and my similar dweb::trove::History) pointers as "likely to be near the head" of the graph. So when getting the head, we use the pointer the candidate GraphEntry and then follow it to the end to ensure we have the head.

I think that should be good enough and will be implementing this for my History.

[markwylde]

I just tried again, been a day and a half, but still not synced.

> markwylde in autonomi % ./target/release/ant register edit --name markwylde5 third
🔗 Connected to the Network                                                                                       Enter password to decrypt wallet:
Attempting to update register at markwylde5 with new value: third
Error:
   0: Failed to update register at address: markwylde5
   1: Corrupt register: Pointer is apparently not at head, attempting to heal the register by updating it to point to the next entry at GraphEntryAddress(25a6d3), please retry the operation

Location:
   ant-cli/src/commands/register.rs:140

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register get --name markwylde5
🔗 Connected to the Network                                                                                       Getting register with name: markwylde5
✅ Register found at: markwylde5
With value: [first]
-------------------------------------------------------------
> markwylde in autonomi % ./target/release/ant register history --name markwylde5
🔗 Connected to the Network                                                                                       Getting register history with name: markwylde5
✅ Register history found at: markwylde5
History of values:
[first]
[second]

@grumbach would you please reopen this issue, if that's okay?

[grumbach]

Thanks guys! Reopened the issue as indeed a "day and a half" is not a reasonable wait time to get a Pointer updated! Will keep digging!

I've got an attempt here to improve Pointer accuracy: #2753 (was merged in main). It managed on my side to fix a similarly broken register after some retries (more register edit). Could you give it a try and tell me if it changes anything (just try on latest main)?

[markwylde]

Thanks @grumbach

This is looking much better. markwylde6 and markwylde7 all went through.

Create a register

> markwylde in autonomi % time ./target/release/ant register create markwylde7 first
🔗 Connected to the Network
Enter password to decrypt wallet:
Creating register with name: markwylde7
✅ Register created at address: a3299e3b74ddf215b39d1ab5b8d36dcb58d65e7a3515b61bd3e8a840e3a9fb53a69a15b0be91a283681de80346f430d2
With name: markwylde7
And initial value: [first]
Total cost: 0.00000000000000000000022410005655 AttoTokens

21.99s user 57.50s system 36% cpu 3:37.11 total

Get the register value

> markwylde in autonomi % time ./target/release/ant register get --name markwylde7
🔗 Connected to the Network
Getting register with name: markwylde7
✅ Register found at: markwylde7
With value: [first]

12.85s user 19.88s system 170% cpu 19.142 total

Update the register value

> markwylde in autonomi % time ./target/release/ant register edit --name markwylde7 second
🔗 Connected to the Network
Enter password to decrypt wallet:
Attempting to update register at markwylde7 with new value: second
✅ Successfully updated register
With value: [second]
Total cost: 0.00000000000000000000000055880967 AttoTokens

16.65s user 40.84s system 57% cpu 1:40.59 total

Confirm the register value is updated

> markwylde in autonomi % time ./target/release/ant register get --name markwylde7
🔗 Connected to the Network
Getting register with name: markwylde7
✅ Register found at: markwylde7
With value: [second]

12.65s user 18.50s system 165% cpu 18.855 total

Edit a third time

> markwylde in autonomi % time ./target/release/ant register edit --name markwylde7 third
🔗 Connected to the Network
Enter password to decrypt wallet:
Attempting to update register at markwylde7 with new value: third
✅ Successfully updated register
With value: [third]
Total cost: 0.00000000000000000000000055880967 AttoTokens

16.11s user 44.55s system 87% cpu 1:09.64 total

Get history

> markwylde in autonomi % time ./target/release/ant register history --name markwylde7
🔗 Connected to the Network
Getting register history with name: markwylde7
✅ Register history found at: markwylde7
History of values:
[first]
[second]
[third]

17.49s user 43.19s system 57% cpu 1:45.41 total

Get latest value

> markwylde in autonomi % time ./target/release/ant register get --name markwylde7
🔗 Connected to the Network
Getting register with name: markwylde7
✅ Register found at: markwylde7
With value: [third]

12.56s user 18.81s system 137% cpu 22.782 total

The timings are quite slow:

ant register get: 19.142s

ant register edit: 100.59s
ant register get: 18.855s

ant register edit: 69.64s
ant register history: 105.41s

ant register get: 22.782s

[happybeing]

we treat the Register (and my similar dweb::trove::History) pointers as "likely to be near the head" of the graph. So when getting the head, we use the pointer the candidate GraphEntry and then follow it to the end to ensure we have the head.

@markwylde I've implemented the above for dweb::trove::History<T> and it works well, except that finding the head of the graph means waiting for an entry at the end to "not be found" on the network.

That takes more than 20s which is too long. So I've:

• managed to avoid this when updating (adding an entry)
• provided some control to enable apps to avoid doing this unless absolutely necessary

On the last point, it means you can for example keep track of the most recent pointer.counter() value and use this to avoid looking for another entry if it matches (or is less than the retrieved pointer.counter())

BTW Mark, I have pushed this to github but not yet to crates.io. I want to update the README before doing that. I have also realised it would be possible to allow History<T> to operate on Register pointer/graphs, but don't yet plan to do this - too many other interesting things.

@grumbach any faster than ~20s ways my code could discover that a GraphEntry doesn't exist would be useful to know about, but I think what I have will do for now. On the other hand if your fix can guarantee pointer update in a few seconds that would avoid the need for much of this. I think that would cover a lot of use cases.

[grumbach]

@markwylde glad this helped fix the issue! Performance is still not ideal indeed!
@happybeing, you can try using:
https://docs.rs/autonomi/latest/autonomi/struct.Client.html#method.graph_entry_check_existance
Which should be faster than a regular graph_entry_get

[happybeing]

FYI graph_entry_check_existance() knocks 0-3s off the 20s on a local testnet.