This issue currently only affects EconomicResource.contains and manifests as nondeterministic return order of contained resources.
It should be resolved as part of #337 and will definitely go away once we move to an integrity zome architecture in #264; but deserves its own issue as there are some additional DHT storage bloat optimisations that might need to be made in addressing it. In short, since hdk_semantic_indexes_zome_lib::sync_index does not currently create time indexes for the destination link targets, and these are triggered separately in hdk_records::identity_helpers::create_entry_identity, you don't actually get bidirectional time indexes created unless you manually request that both sides of an index be created. This breaks for self-referential indexes, since only 1 RPC call is made to update them (both sides being in the same zome means this is sufficient for updating the semantic indexing components of the link structure).
This issue currently only affects
EconomicResource.containsand manifests as nondeterministic return order of contained resources.It should be resolved as part of #337 and will definitely go away once we move to an integrity zome architecture in #264; but deserves its own issue as there are some additional DHT storage bloat optimisations that might need to be made in addressing it. In short, since
hdk_semantic_indexes_zome_lib::sync_indexdoes not currently create time indexes for the destination link targets, and these are triggered separately inhdk_records::identity_helpers::create_entry_identity, you don't actually get bidirectional time indexes created unless you manually request that both sides of an index be created. This breaks for self-referential indexes, since only 1 RPC call is made to update them (both sides being in the same zome means this is sufficient for updating the semantic indexing components of the link structure).