Expected behaviour on identical 'update_entry'

Technical Discussion App Development
#1

Hi all!

With @hedayat we are writing the example hApp LeaP for the DevCamp 6. We have come across a bug that has surfaced a question.

This is the situation: in our hApp, we have a course entry with an array of module entry addresses, a name, a teacher address and a timestamp. Here is the design if anyone wants more detail: https://hackmd.io/_Uvrwr1HSNmfsWHqymcgvA.

At first, course is created only with its name, teacher and timestamp, with no modules. When we add a module to the course, the course entry is updated. But, if we remove all modules from the course, we are calling update_entry with the exact same contents of the entry as the original entry that we had created.

At this point, Holochain hangs. It does not respond to requests anymore, and we think this is a bug in core.

But, this leads to another question, which is: what is the expected behaviour in this case? Will holochain be smart enough to recognize that this new update is part of that same entry’s chain? Should we develop happs preventing this from ever happening?

Tagging @pauldaoust, maybe you can shed some light in this? We want to have the best responses for the participants of the DevCamp.

1 Like
#2

The core devs recognised this as an issue a while ago, but it was only solved for the special case of updating from A→A and not A→B→A like you’re seeing.

What’s the timestamp for in your existing structure? Is it a written-on timestamp? If so, that should be enough to distinguish the old empty version from the new empty version and avoid CRUD history loops. That is, every editor must put a new timestamp in there.

#3

for visibility: I just talked to @hedayat (HoloPort support call, and then we got talking…), who suggested that, in order to avoid this confusing issue, noncing entries should be an opt-in setting for any entry type. The core team’s practice is to take any recurring pattern and incorporate it into the framework level, so this might be worth bringing up with them.

I’m collecting a list of dev experience suggestions on a Trello board; just captured this issue. I’m hoping to have regular calls with core dev in which I bring up these things.