For the below, let us assume that all participant nodes have all information/transactional data. It is only the parties that have limitations of visibility based on their actAs/ReadAs.
What sort of differences in data structures (if any) occur when the request party asks for the transaction tree: Is it always “all or nothing” ? Is it just a limitation of the List of Events? etc
Do Exercise Results get omitted but the party can still see the ExercisedEvent?
When events occur “out of order” as described in the link above, does that mean the participant nodes log these as different Event Ids (with a different order number at the end?) or are the IDs the same but some are just missing? (such as 0,1,2,3,4 events vs 0,2,4)
Based on Caching data from ledger: data visibility rules? - #2 by cocreature, if a transaction tree subscription was made with NoFilter applied, so it sees “Everything”, the visibly rules would essentially become "If requesting user has actAs or readAs on any of the witnessParties " ?
recap: think the biggest clarification to understand is how/if data structure/content changes vs it is just the entire objects are not provided: When transactions are being returned based on a party, is there scenarios where the transaction is returned but with field omitted and/or less data than the actual transaction. And what scenarios would occur where the entire transaction would not be returned?
To clarify, all participants where a party is allocated must have all data for that party.
You will see a list of TransactionTrees, (each containing a collection of Events) where each item in the list is a sub-tree of the full transaction, filtered based on the privacy rules specified in your Daml model and the parties you specified in your request (and for which you have a valid readAs or writeAs). The sub-tree will be the full tree if you are an informee of the root event of the transaction tree, otherwise strictly a sub-tree. The tree will be skipped if no party is any informee in any even in the transaction.
No, exercise results should never be omitted if you can see the corresponding exercise.
I’m not sure there’s a specific Ledger API guarantee in this regard, so in any case I wouldn’t make assumptions on it. In practice, I believe the latter, but I’ll let someone else double check my statement.
Consider that transaction trees cannot be filtered by template, only by party. This is despite both via the Ledger API and the Java bindings you can, in principle, pass a full transaction filter as you would for “flat transactions” and the active contracts service, but IIRC you should be getting a runtime error in return if you try to pass a template filter. I believe this was done to leave the future possibility open without making API changes. We’re still evaluating the possibility at the Ledger API level. At the Java bindings level, we’re thinking of adding the possibility of passing a set of parties instead of a full filter as an ergonomics improvement.
Apart from this, and replying more directly to the question, you’ll see the entirety of all data you’re expected to see as the parties you specified (and for which you have a valid readAs token). IIRC you’re still expected to pass parties explicitly on the Java bindings alongside with your readAs as specified by the token or user management service.
This is correct for topologies where the party is allocated on exactly one participant. If a party is allocated on several participants (this is an experimental feature in 2.3.x), then the participants do not need to have the same data for this party. See Daml ledger interoperability for the theoretical background and generalization of the local ledgers model.
Events within a transaction are totally ordered and never re-ordered. So their event IDs will remain in the same relative order. It is not specified whether the the event ID of a node in the transaction tree may change its event ID under projection. AFAIK the event ID remains stable in the current implementation, but we want to retain the ability to revisit this implementation choice in the future.
Projections of transactions as a whole however can be reordered in theory. In practice, this happens in the 2.3.x release only if the transaction tree streams are obtained from different participant nodes. Like for event IDs, the implementation may change in the future and then it may be be possible that subscriptions for different sets of parties serve the common transaction trees in different orders. Accordingly, the offsets in those streams are also specific to the subscription and not comparable, whereas the transaction IDs remain the same.