[fastx adapter] We do not update the previous_transaction of mutable objects

[gdanezis]

Each object has a previous_transaction field which needs to contain the transaction digest that created or mutated the object last. However, right now we seem to not do that in the adapter, and have objects around with inconsistent state (new contents, old previous_transaction).

In PR #311 I added a hack to the temp_storage to add this information on object write. However this is fragile since we may use this information elsewhere (right now I do not think we do).

What about the type checking logic that provides the mutable objects to the execution, ensuring the tx_digest in previous_transaction is correct, somewhere around here?
https://github.com/MystenLabs/fastnft/blob/e856db7503c5c0218f65bde07e34c068abf9f2de/fastx_programmability/adapter/src/adapter.rs#L562

[gdanezis]

@oxade Is this now being taken care of?

[oxade]

@oxade Is this now being taken care of?

@gdanezis I will revisit this today and finalize the PR

[gdanezis]

@oxade any news :)

[oxade]

@oxade any news :)

I was not happy with the initial impl here #587 since its messy
I'm trying to do the enforcement in one central place but the risk is that we may have objects in inconsistent states in the adapter/authority. Working on a cleaner soln for this

[lxfind]

It turns out that we are not updating previous_transaction properly in some paths.
Basically, relying on doing so in write_object is a bit fragile. We need to find a more robust way.

[oxade]

It turns out that we are not updating previous_transaction properly in some paths. Basically, relying on doing so in write_object is a bit fragile. We need to find a more robust way.

Can you pinpoint exactly what the holes are?
And can you see if this original impl I had covered all the edge cases? Granted it can be refined.

[lxfind]

It turns out that we are not updating previous_transaction properly in some paths. Basically, relying on doing so in write_object is a bit fragile. We need to find a more robust way.

Can you pinpoint exactly what the holes are? And can you see if this original impl I had covered all the edge cases? Granted it can be refined.

In fact, it would have! What we are missing in this case is the code in ensure_active_inputs_mutated. I don't know if there are other new cases though.

[oxade]

It turns out that we are not updating previous_transaction properly in some paths. Basically, relying on doing so in write_object is a bit fragile. We need to find a more robust way.

Can you pinpoint exactly what the holes are? And can you see if this original impl I had covered all the edge cases? Granted it can be refined.

In fact, it would have! What we are missing in this case is the code in ensure_active_inputs_mutated. I don't know if there are other new cases though.

Great. Should I revive the core logic in the PR or do you wanna take this up?

[lxfind]

I will probably take a look