-
Notifications
You must be signed in to change notification settings - Fork 704
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
Add defensive testing extrinsic #1998
Conversation
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."); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 😆
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 |
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 |
It needs to be changed in the macros to
|
Ohh yes I saw that. I thought we needed to implement something more difficult haha. I've made the change. |
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. |
@adelarja, having logs printed as |
Seeing this in the CI:
Mostly all CI checks should be green. Once that is, we should be good to merge. |
…a/polkadot-sdk into 1953-defensive-testing-extrinsic
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
# 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>
* 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
Description
The
trigger_defensive
call has been added to theroot-testing
pallet. The idea is to have this pallet running onRococo/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
T
required)
You can remove the "Checklist" section once all have been checked. Thank you for your contribution!
✄ -----------------------------------------------------------------------------