Inspect_message for Motoko

Is the inspect_message function planned for Motoko in the near future?

Also, will inspecting and discarding an ingress message with a large payload prevent the canister from being charged cycles, other than the cost of cycles for the inspect_message function itself?

Lastly, even if Motoko gets inspect_message, how can a canister defend against a hacker deploying another canister and sending large inter-canister payloads to a function in a constant loop? I imagine the function logic could throttle or block repeated requests from the same principal (saving storage), but afaik, the cycles will still get drained.



Bump. What is the status of inspect_message for motoko?


Stalled in bikeshedding Feature: support system method `inspect-message` · Issue #2528 · dfinity/motoko · GitHub


Will this be taken up again soon? I think inspect_message can be really valuable to use for early authentication in order to prevent cycle drainage attacks.


I may have a go at this this week.

If you have an strong opinion about the proposals in (Feature: support system method `inspect-message` · Issue #2528 · dfinity/motoko · GitHub)

do chime in.


I have a strong opinion that it’s needed. Without the ability to intercept messages, any canister written with Motoko is vulnerable to a cycle drain attack.


Is this live in Motoko?


Yes, it should be. Try it from the playground.


Thank you Claudio!!!

I’m currently unable to restrict query or shared query functions with inspect_message (update calls work fine).

I took the example from the documentation and put it on the playground.

Its probably not kicking in for queries because the playground issues them as query, not update, ingress messages. But I’m not sure.

inspect_message doesn’t apply to query calls. See the interface spec: The Internet Computer Interface Specification | Internet Computer Home


Got it, thanks!

@claudio then the docs here should remove the query call from the inspect_message call? Does it make sense for query calls to be included in the msg arg since they won’t be blocked regardless of the boolean returned?

1 Like

Confusingly, a shared query function can be called using a regular HTTP call to obtain a certified response: this is why the variant type also includes shared query functions.

You would probably need to use dfx with a manually issued, certified (not plain) query to observe the filtering.

If you are trying to restrict something you could force an update by using the http_upgrade header which would force an update.

A “nice-to-have” would be if inspect_message could apply to query calls as well. Any idea how difficult this change would be?

Okay, I’m confused. You mean I can call the shared query function as an update method, and this update call can be filtered by inspect_messge? Is this mentioned in the spec?

I understood that inspect_message is there so that you can run some code on one replica first before it goes through the expensive process of being run on all replicas. So for a query call (that is called as a query call) you can just put the filtering code directly into the query function. You don’t need inspect_message to achieve the same result.


Yes, I believe so, if you squint at the spec. The calls goes through concensus, state changes are transient, and filtering is applied. IIRC.