Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Add test suite and minor refinements to the utility subsystem #1403

Merged
merged 17 commits into from
Jul 21, 2020

Conversation

coriolinus
Copy link
Contributor

No description provided.

Unfortunately, the test fails right now for reasons which seem
very odd. Just have to keep poking at it.
@coriolinus coriolinus self-assigned this Jul 14, 2020
@github-actions github-actions bot added the A3-in_progress Pull request is in progress. No review needed at this stage. label Jul 14, 2020
@coriolinus coriolinus added B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Jul 15, 2020
let _ = async move { unordered.collect::<Vec<_>>() }.await;
.collect::<FuturesUnordered<_>>()
.map(Ok)
.forward(drain())
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

The root problem here was two-fold:

- there was a circular dependency from subsystem -> test-helpers/subsystem ->
  subsystem
- cfg(test) doesn't propagate between crates

The solution: move the subsystem test helpers into a sub-module
within subsystem. Publicly export them from the previous location
so no other code breaks.

Doing this has an additional benefit: it ensures that no production
code can ever accidentally use the subsystem helpers, as they are compile-
gated on cfg(test).
@coriolinus coriolinus marked this pull request as ready for review July 16, 2020 15:08
@github-actions github-actions bot added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Jul 16, 2020
@coriolinus
Copy link
Contributor Author

coriolinus commented Jul 17, 2020

Interestingly, the same test fails in two runs on CI, but I can't get it to fail locally on Ubuntu or OSX over several runs. I'd prefer not to just delete the test. Does anyone here have experience with failures like this?

Log tests weren't the best idea in the first place, so I replaced that whole system in f0c23de

It's not obvious whether we'll ever really want to chase down
these errors outside a testing context, but having the capability
won't hurt.
also fix polkadot-node-core-backing tests
rx_to: mpsc::Receiver<Self::ToJob>,
tx_from: mpsc::Sender<Self::FromJob>,
receiver: mpsc::Receiver<Self::ToJob>,
sender: mpsc::Sender<Self::FromJob>,
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

if let Some(mut err_tx) = err_tx {
// if we can't send the notification of error on the error channel, then
// there's no point trying to propagate this error onto the channel too
let _ = err_tx.send((Some(parent_hash), JobsError::Job(e))).await;
Copy link
Contributor

@drahnr drahnr Jul 17, 2020

Choose a reason for hiding this comment

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

should we print a warning here at least? This seems to be a more general question how we want to handle these cases.

Copy link
Contributor

@drahnr drahnr left a comment

Choose a reason for hiding this comment

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

Mostly one question how we want to handle cases where channels are saturated / unabled to send to the overseer? I am in favor of warn!

Combine tests of starting and stopping job: leaving a test executor
with a job running was pretty clearly the cause of the sometimes-hang.

Also, add a timeout so tests _can't_ hang anymore; they just fail
after a while.
node/subsystem/src/lib.rs Outdated Show resolved Hide resolved
///
/// This variant is only valid while testing, but makes the process of testing the
/// subsystem job manager much simpler.
#[cfg(test)]
Copy link
Member

Choose a reason for hiding this comment

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

do we want #[cfg(any(test, feature = "test-helpers"))] here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No: this is only used within the internal unit tests of the job manager. If we come up with a use for it later, we can add it then. Until then, I think YAGNI is the better part of valor.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants