RawModuleDefV10 Scheduled functions should not be callable

[Shubham8287]

Description of Changes

• Codegen to skip creating reducer and procedure file if visibility == FunctionVisiblity::Internal
• UpdateHost to check for visibility before excuting reducers and procedures.

API and ABI breaking changes

NA, master is not exposing new raw module version yet.

Expected complexity level and risk

1. While the current patch is simple, could there be other places where visibility should also be applied?

Testing

Smoketest can be in 2.0-breaking-changes branch once we merge this.
Exising test should cover for regression

[cloutiertyler]

Wait, doesn't the module owner still need the option/ability to call private reducers?

[Shubham8287]

Wait, doesn't the module owner still need the option/ability to call private reducers?

Well, if that’s the case, then I misunderstood the requirement. I thought they were only meant to be called by the Host.

[gefjon]

Re: making internals callable by the owner, I would suggest that:

1. Until/unless we get a feature like "codegen profiles," internal reducers should not be included in codegen for the SDKs, and it is not useful to make them callable through the WebSocket API.
2. Allowing the owner / admins to call internal reducers via the CLI, and therefore via the HTTP API, is potentially valuable, but I would not consider it a requirement. It's very easy, with a small amount of additional module code, for a user who wants such a thing to make (the code contained in the body of) an internal reducer client-callable.

[cloutiertyler]

Well, if that’s the case, then I misunderstood the requirement. I thought they were only meant to be called by the Host.

This would break BitCraft's workflow as they sometimes need to be able to call scheduled reducers manually. I believe that wholly disallowing is a regression.

Note for example that the roadmap item says "Make scheduled reducers internal by default" (emphasis mine). It is not that scheduled reducers are only callable by the module.

I think this ticket was also just underspecified in general. I would add the following requirements:

1. We call it private instead of internal.
2. private has the same semantic meaning as a private table. (accessible only by the module, the owner, or collaborators)
3. Scheduled reducers are private by default
4. You can declare them public with:

#[reducer(public)]
fn foobar() {
   // ...
}

[gefjon]

Well, if that’s the case, then I misunderstood the requirement. I thought they were only meant to be called by the Host.

This would break BitCraft's workflow as they sometimes need to be able to call scheduled reducers manually. I believe that wholly disallowing is a regression.

Note for example that the roadmap item says "Make scheduled reducers internal by default" (emphasis mine). It is not that scheduled reducers are only callable by the module.

I think this ticket was also just underspecified in general. I would add the following requirements:

1. We call it `private` instead of internal.

2. `private` has the same semantic meaning as a `private` table. (accessible only by the module, the owner, or collaborators)

3. Scheduled reducers are `private` by default

4. You can declare them public with:

#[reducer(public)]
fn foobar() {
   // ...
}

It was my understanding that we would, in fact, do exactly your 4 here, we just didn't need to do so in the MVP.

[gefjon]

Ok @Shubham8287 , per discussion with @cloutiertyler out-of-band, please:

• Change terminology for these reducers from "Internal" to "Private," including in the ModuleDef and RawModuleDefV10 definitions.
• Adjust call_reducer so that it checks if the sender identity is the owner or a collaborator before invoking, rather than unconditionally rejecting.
• Leave it so that private reducers do not get client codegen, though please do think about my previous comment about codegen for reducer events.