SNS validate and execute functions in Motoko

Hey everyone, I’m working on an SNS test flight I have a few questions around executing code via proposals. Let’s say my goal is to run a greet function from a proposal:

public shared func greet() : async Result.Result<Text,Text>{
        
       
        return #ok("hello");
    };

It is my understanding from the documentation that the canister containing the greet function should also contain a validate and execute function, is this correct?

Is there an example in Motoko available anywhere, I’ve only found this one in rust?

The ‘execute function’ is the one you’ve already written. And yes, you need to also add a validation function, although it doesn’t need to be on the same canister IIRC, even though that is by far the easiest way to do it.

Since your function does not take any arguments the validation function is pretty useless, but the interface requires it. In your case I’d add this function:

public shared func greet_validate() : async Result.Result<Text,Text>{
        return #ok("unit argument");
    };
3 Likes

Ah I see that clears things up for empty arguments.

Let’s say the function did take an argument, is the purpose to validate the payload for parameters I’ve decided on, for example let’s say I want to be sure the payload is only 5 chars long?

Then in the case of a payload, greet_validate would intake the payload as a string and return an error if the payload is greater than 5 chars?

Yes, you got it :+1:

1 Like

Awesome, out of curiosity, is there some technical concern why we couldn’t just validate within the function it self?

Not 100% sure on that one, but I think part of creating the proposal is to validate the arguments already. There’s no purpose to voting on a proposal that’s invalid. Also, I think the Ok(string) is used to display the thing you’re voting on. So e.g. for a new canister wasm you’d feed the wasm into the validate function, which could e.g. check if the wasm is valid, and then return the hex encoding of the hash of the wasm. This way people can verify that you’re indeed voting on the right piece of code, and not some arbitrary other wasm

2 Likes

Is it possible this is the ok vs Ok issue between rust and motoko?

The request is being processed...
(
  record {
    command = opt variant {
      Error = record {
        error_message = "1 defects in Proposal:\nError decoding reply from proposal payload validate and render call: Fail to decode argument 0 from table0 to variant { Ok : text; Err : text }";
        error_type = 15 : int32;
      }
    };
  },
)

Here is the motoko function I am testing for reference:

public shared func testSNSFunctionCalls() : async Text {
       
       return "testing 1..2..3..";
    };

    public shared func validate_testSNSFunctionCalls() : async Result.Result<Text, Text> {
       return #ok("testing 1..2..3..");
    };

Most likely, yes. I think you ‘just’ have to declare your own result type that contains the upper case version…

2 Likes

Worked, thanks again :pray:

1 Like