Check Checker: question about toml settings

[whoabuddy]

We were experimenting with callee_filter = true in the CityCoins protocol (being updated here on this branch).

This produced varying results with a public function that checks data through private functions.

The mine public function in contracts/extensions/ccd006-city-mining.clar folds over mine-block with response data, which calls a few other read-only/private functions to complete mining, including the private function set-mining-data.

Adding the callee_filter = true required us to add filters to each private function, but they are designed to unwrap a value successfully or return an error.

It would be great if we had a way to mark that a function will only accept clean data.

It also seems like trusted_sender = true and trusted_caller = true didn't have the intended effects on functions within the xDAO model, including:

• is-dao-or-extension in contracts/base-dao.clar
• is-self-or-extension in contracts/extensions/*

We're working to reduce some of the check checker errors in the branch linked above so we can dig into the more meaty ones!

[whoabuddy]

Expanding on this a bit:

• For ccd006-city-mining.clar and ccd007-city-stacking.clar we're using the filter annotation on private functions. This is working with callee_filter = true set.
• The majority of remaining warnings are related to guarded functions that first check if the tx is being completed by the DAO or an extension (via is-dao-or-extension), or guarded functions that check is-self-or-extension first. In those cases we'd like to indicate that the input should be trusted.
• Toggling trusted_sender and trusted_callee does not remedy the majority of them as expected. It's also difficult to see what changed given the number of warnings, and the fact the diffs don't match up well using clarinet check > filename:
  • trusted_off.txt
  • trusted_on.txt
  • setting both as true removed ~5 warnings (not exact because of #721)

Example of git diff --no-index between both text files above:

Shouldn't the files be created in the same order each time? Is there a better way to help visualize the diff here?

From there we still have some edge cases but so far the warnings are slowly getting cleaned up!

[lgalabru]

Shouldn't the files be created in the same order each time? Is there a better way to help visualize the diff here?

hey @whoabuddy! thanks for raising this issue. I noticed this issue, it is pretty annoying, specially in the context of deployments plans - dependencies get re-ordered, creating useless differences. I'll try to address this issue soon.

[lgalabru]

Ordering issue should be addressed with https://github.com/hirosystems/clarinet/pull/716/commits/cf8140e6534bfc1a2f01c09addcae3a45d85d290