Summary or problem description
The original issue is described in #3299 (comment). If ApplicationLog has stackitem that fails to be serialized, it's replaced by the Null stackitem:
|
_snapshot.Put(key, BinarySerializer.Serialize(StackItem.Null, ExecutionEngineLimits.Default with { MaxItemSize = (uint)Settings.Default.MaxStackSize })); |
It's not correct from the end-user POW since there's no way to distinguish the "good" original stackitem from the result of invalid seialization.
Do you have any solution you want to propose?
Use a special stackitem stub with InvalidT type which can't be produced by any means other than exception during serialisation. With this special type there's no doubts from the user side whether there was an exception during serialization or not. This approach is implemented in NeoGo, see https://github.com/nspcc-dev/neo-go/blob/cf4d4a2611209d8d085ccec6e1f1b8956006a577/pkg/vm/stackitem/serialization.go#L144.
Where in the software does this update applies to?
Summary or problem description
The original issue is described in #3299 (comment). If ApplicationLog has stackitem that fails to be serialized, it's replaced by the
Nullstackitem:neo/src/Plugins/ApplicationLogs/Store/LogStorageStore.cs
Line 164 in 6e8c730
It's not correct from the end-user POW since there's no way to distinguish the "good" original stackitem from the result of invalid seialization.
Do you have any solution you want to propose?
Use a special stackitem stub with
InvalidTtype which can't be produced by any means other than exception during serialisation. With this special type there's no doubts from the user side whether there was an exception during serialization or not. This approach is implemented in NeoGo, see https://github.com/nspcc-dev/neo-go/blob/cf4d4a2611209d8d085ccec6e1f1b8956006a577/pkg/vm/stackitem/serialization.go#L144.Where in the software does this update applies to?