Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add defensive testing extrinsic #1998

Merged
merged 12 commits into from
Oct 31, 2023

Conversation

adelarja
Copy link
Contributor

@adelarja adelarja commented Oct 24, 2023

Description

The trigger_defensive call has been added to the root-testing pallet. The idea is to have this pallet running on Rococo/Westend and use it to verify if the runtime monitoring works end-to-end.

To accomplish this, trigger_defensive dispatches an event when it is called.

Closes #1953

Checklist

  • My PR includes a detailed description as outlined in the "Description" section above
  • My PR follows the labeling requirements of this project (at minimum one label for T
    required)
  • I have made corresponding changes to the documentation (if applicable)
  • I have added tests that prove my fix is effective or that my feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank you for your contribution!

✄ -----------------------------------------------------------------------------

@adelarja adelarja requested review from a team October 24, 2023 03:21
@paritytech-ci paritytech-ci requested a review from a team October 24, 2023 10:20
@ggwpez ggwpez added the T2-pallets This PR/Issue is related to a particular pallet. label Oct 24, 2023
@ggwpez
Copy link
Member

ggwpez commented Oct 24, 2023

Good so far, now please also deploy to Rococo/Westend (as hinted in the issue #1953).

#[pallet::weight(0)]
pub fn trigger_defensive(origin: OriginFor<T>) -> DispatchResult {
ensure_root(origin)?;
frame_support::defensive!("root_testing::trigger_defensive was called.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggwpez so you want this to panic? I don't really get what you want to achieve?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

defensive is just log error and debug_assert, which is nop on release build, so this is a bit pointless. if you want to test log error, just log error.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I know that this is using a debug assert, I was assuming @ggwpez wants to build with debug asserts enabled and then use it as overwrite.

Copy link
Member

@ggwpez ggwpez Oct 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea here is that we are currently not sure if the monitoring correctly picks up defensive failures. And we really should be notified about them, so this is just as test.
It could also be logged, but the defensive! macro also logs a magic string (DEFENSIVE_OP_PUBLIC_ERROR) that we can filter for and alert in the grafana.
Then we can call this and check that we got notifications in chat about this failure.

@paritytech-ci paritytech-ci requested a review from a team October 25, 2023 09:41
Copy link
Member

@ggwpez ggwpez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
cc @PierreBesson I hope you are prepared 😆

@PierreBesson
Copy link

I would suggest to use a new special log level ("log target" in rust) called DEFENSIVE. This will make it easier to identify those log in monitoring systems as the log level can be easily indexed in systems such as Grafana Loki.

@ggwpez
Copy link
Member

ggwpez commented Oct 27, 2023

I would suggest to use a new special log level ("log target" in rust) called DEFENSIVE. This will make it easier to identify those log in monitoring systems as the log level can be easily indexed in systems such as Grafana Loki.

Oh yea, did not think about this. Currently we just use runtime, but we could switch it to runtime::defensive.
Could you please also do this @adelarja?

@adelarja
Copy link
Contributor Author

I would suggest to use a new special log level ("log target" in rust) called DEFENSIVE. This will make it easier to identify those log in monitoring systems as the log level can be easily indexed in systems such as Grafana Loki.

Oh yea, did not think about this. Currently we just use runtime, but we could switch it to runtime::defensive. Could you please also do this @adelarja?

Sure, I can do it. But I'm not entirely sure about what do we need to do.

@PierreBesson do you mean doing something like:

log::info!(target: "DEFENSIVE", "Example log!");

@ggwpez Where are we setting the target to runtime?

@ggwpez
Copy link
Member

ggwpez commented Oct 28, 2023

@ggwpez Where are we setting the target to runtime?

It needs to be changed in the macros to runtime::defensive please:

@adelarja
Copy link
Contributor Author

@ggwpez Where are we setting the target to runtime?

It needs to be changed in the macros to runtime::defensive please:

Ohh yes I saw that. I thought we needed to implement something more difficult haha. I've made the change.

@ggwpez
Copy link
Member

ggwpez commented Oct 29, 2023

Looks like there is a conflict with master, could you please resolve the conflicts? Then we can merge.

@adelarja
Copy link
Contributor Author

adelarja commented Oct 30, 2023

Looks like there is a conflict with master, could you please resolve the conflicts? Then we can merge.

Fixed. The rococo and westend tests are passing.

@PierreBesson
Copy link

PierreBesson commented Oct 30, 2023

@PierreBesson do you mean doing something like:

log::info!(target: "DEFENSIVE", "Example log!");

@adelarja, having logs printed as runtime::defensive as @ggwpez suggested will do the job nicely. I see that you have already implemented this 👍 .

@adelarja adelarja changed the title [WIP] 1953 defensive testing extrinsic 1953 defensive testing extrinsic Oct 30, 2023
@ggwpez
Copy link
Member

ggwpez commented Oct 31, 2023

Seeing this in the CI:

error[E0046]: not all trait items implemented, missing: `RuntimeEvent`
   --> substrate/frame/utility/src/tests.rs:190:1
    |
 190 | impl pallet_root_testing::Config for Test {}
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `RuntimeEvent` in implementation
    |
    = help: implement the missing item: `type RuntimeEvent = /* Type */;`

Mostly all CI checks should be green. Once that is, we should be good to merge.

adelarja and others added 3 commits October 31, 2023 11:11
…a/polkadot-sdk into 1953-defensive-testing-extrinsic
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
@ggwpez ggwpez merged commit 6e2f94f into paritytech:master Oct 31, 2023
109 of 110 checks passed
@ggwpez ggwpez changed the title 1953 defensive testing extrinsic Add defensive testing extrinsic Oct 31, 2023
bgallois pushed a commit to duniter/duniter-polkadot-sdk that referenced this pull request Mar 25, 2024
# Description

The `trigger_defensive` call has been added to the `root-testing`
pallet. The idea is to have this pallet running on `Rococo/Westend` and
use it to verify if the runtime monitoring works end-to-end.

To accomplish this, `trigger_defensive` dispatches an event when it is
called.

Closes paritytech#1953

# Checklist

- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
- [ ] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
serban300 pushed a commit to serban300/polkadot-sdk that referenced this pull request Mar 26, 2024
* try revert separate cargo fetch

* Revert "try revert separate cargo fetch"

This reverts commit 906f53483a2ca588e73d94b63e7d2b079bf9870c.

* try cargo fetch for wasm32-unknown-unknown

* run cargo test with runtime-benchmarks feature only
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T2-pallets This PR/Issue is related to a particular pallet.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

defensive! testing extrinsic
5 participants