IDL Hashing does not follow upgrade spec

[Kai Peacock]

Describe the bug
By adding a new field to an error variant, I get back an error Cannot find field hash _2102411630_ when using a version of the generated delcarations without the new variant.

To Reproduce

1. Deploy canister with type

  public type CreateInvoiceErr = {
    message : ?Text;
    kind : {
      #BadSize;
      #InvalidToken;
      #InvalidAmount;
      #InvalidDestination;
      #InvalidDetails;
      #MaxInvoicesReached;
      #Other;
    };
  };

2. Generate declarations
3. Add type #NotAuthorized;
4. Redeploy, and make call using prior declarations

Expected behavior
Agent JS should make the call without the most up to date interface

[Kai Peacock]

@chenyan-dfinity would you agree that this behavior is incorrect as-is?

[Yan Chen]

With the current implementation, I think we won't get the error unless you are sending the new tag #NotAuthorized as the value.

With the new spec change, the error variant should also be inside an opt value, so that when the client sees an unknown tag, we change it to null. See dfinity/candid#295. This has not been implemented in JS yet.

[Kai Peacock]

I'm getting the error when receiving the new tag from the canister. Could we switch to a console.warn approach, while allowing the application logic to decide how to handle the unexpected tag?

[Yan Chen]

That's the goal. The error type should be opt CreateInvoiceErr, then null indicates the unknown tag.