What are the rules for submitting commands that result in operations on contract keys?
Scenario: a submitter S is using the participant P to submit a command (with no authorization problems) that ultimately performs an exercise/fetch/lookup by key on a key K. P has seen a contract C that has the key K, and C hasn’t been archived (or P hasn’t seen it get archived).
what happens if C is active and S is a stakeholder, but not a key maintainer on C?
a) what happens for a lookup?
b) what happens for an exercise or a fetch?
what happens if C is active and S is not a stakeholder on C, but has previously witnessed C?
a) what happens for a lookup?
b) what happens for an exercise or a fetch?
if an exercise fails or a lookup returns None in any of the above scenario: why?
for completeness, what happens if S hasn’t previously witnessed C?
The current rules are simple: During interpretation, lookupByKey, fetchByKey and exerciseByKey work exactly in your scenario 1., regardless of S being a maintainer or not.
That also means that in your scenario 2. all three fail. The lookup in 2. is somewhat special as it will fail during validation, not interpretation like the others. During interpretation, the lookupByKey will result in a None that will later be rejected.
Scenario 4. is indistinguishable from 2.
To answer your point 3.: Lookups and exercises fail in 2. because we don’t consider witnessed contracts to be part of the active contract set of a party. The fact that witnessed contracts can be fetched is unfortunate in my opinion. It encourages the use of divulgence for disclosure, which is not it’s purpose and for which it is quite poorly suited. Since you can witness multiple contracts with the same key and may not be able to order them causally, extending the ability to use witnessed contracts in key lookups is not trivial, either. The participant node may either end up having to make fairly arbitrary choices how to resolve the key.