fix(zoe): add terms to invite details

[erights]

Fixes #5903

Invitation amounts now include terms in the details as info accoring to zoe (as opposed to customDetails, which is info according to the contract).

[datadog-full-agoric]

Datadog Report

Branch report: markm-5903-add-terms-to-invite-details
Commit report: 33247ea

❌ agoric-sdk: 2 Failed (0 Known Flaky), 0 New Flaky, 2146 Passed, 22 Skipped, 17m 35.87s Wall Time

❌ Failed Tests (2)

• smartWallet › oracle-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

• smartWallet › psm-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

[Chris-Hibbert]

Why are empty brands and issuers (and a duplicate of the data that will end up in terms) being included in the custom details? It seems a distracting and unenlightening choice to include in customTerms.

It could be anything, right? It doesn't have anything to do with the brand and issuers in the top-level terms. So it could completely contradict the real info according to Zoe. Wouldn't a better example either show that these brands and issuers are completely separate info or show that they're arbitrary fields according to the contract?

[erights]

The point is to add terms itself to the regular invitation details, the part according to zoe, not the customDetails, which is not clearly separated as the part according to the contract.

I don't understand the reference to customTerms. IIUC, customTerms is the part of terms aside from the brands and issuers. If we think of the customTerms rather than the terms as being the parameters of the contract, that could be an argument for only including the customTerms, not the full terms, in the invitationDetails.

It doesn't have anything to do with the brand and issuers in the top-level terms. So it could completely contradict the real info according to Zoe.

This is the key issue. The entire purpose of this PR is to introduce only the terms according to Zoe. The PR is trash until it succeeds at that.

The relevant lines are

const instanceRecord = state.instanceState.getInstanceRecord();
...
   terms: instanceRecord.terms,

Is state.instanceState.getInstanceRecord().terms the terms according to Zoe? In what ways can the contract influence the contents of this field?

[Chris-Hibbert]

I'm confused by the following snippet. Why does terms appear twice in these invitation details? The deeper one seems to be at the discretion of the contract (it's under customDetails).

  t.deepEqual(details, {
    description: 'myInvitation',
    handle: details.handle,
    installation,
    instance,
    terms: {
      brands: {},
      issuers: {},
    },
    customDetails: {
      description: 'whatever',
      installation: 'whatever',
      instance: 'whatever',
      terms: {
        brands: {},
        issuers: {},
      },
    },
  });

[Chris-Hibbert]

Invitation amounts now include terms in the details as info accoring to zoe (as opposed to customDetails, which is info according to the contract).

Which documentation needs to be updated to explain what info in an invitation is guaranteed with what veracity according to which authority?

cc: @Tyrosine22

[datadog-full-agoric]

Datadog Report

Branch report: markm-5903-add-terms-to-invite-details
Commit report: 1f92f6e

❌ agoric-sdk: 4 Failed (0 Known Flaky), 0 New Flaky, 2391 Passed, 29 Skipped, 20m 5.18s Wall Time

❌ Failed Tests (4)

• smartWallet › oracle-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

• smartWallet › oracle-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

• smartWallet › psm-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

• smartWallet › psm-integration › before hook - agoric.inter-protocol - Details

  Expand for error

   ---
       name: AssertionError
       message: Rejected promise returned by test
       values:
         'Rejected promise returned by test. Reason:': |-
           Error {
             message: 'In "startInstance" method of (ZoeService): arg 2?: A "promise" cannot be a key',
           }
       at: >-
         throwLabeled (packages/internal/src/utils.js:110:27)
   ...
  

[erights]

Converted to draft because this is a durable representation change which needs upgrade coordination