Integration test fails in test helper script

[taqtiqa-mark]

This integration test case that ran under v0.4.1 now abends inside a test utility script.

Failing an integration test inside test helper scripts is, IMO, undesirable. I believe the error should be handled at dev time, compile time or at run time.

I don't believe this test case can be eliminated. My conjecture would be that this issue should be handled in the type design, and will then be caught at compile or dev time. Until then we likely have to live with this silently failing. Documentation and examples are workarounds until a fix lands for this test case.

Thoughts?

extern crate alloc;
use minitrace::trace;
use minitrace::prelude::*;
use test_utilities::*;

// With default (`enter_on_poll = false`), `async` functions construct
// `Span` that is thread safe.
//
// With no block expression the child span is silently omitted.
// Reference:
// - https://github.com/tikv/minitrace-rust/issues/125
// - https://github.com/tikv/minitrace-rust/issues/126
#[trace]
async fn test_async(a: u32) -> u32 {
    a
}

#[trace]
fn test_sync(a: u32) -> u32 {
    a
}

#[tokio::main]
async fn main() {
    let (reporter, records) = minitrace::collector::TestReporter::new();
    minitrace::set_reporter(reporter, minitrace::collector::Config::default());
    let root = Span::root("root", SpanContext::random());
    let _child_span = root.set_local_parent();
    let mut handles = vec![];

    handles.push(tokio::spawn(test_async(1)));
    test_sync(2);

    futures::future::join_all(handles).await;
    drop(root);
    let _expected = r#"[
    SpanRecord {
        id: 1,
        parent_id: 0,
        begin_unix_time_ns: \d+,
        duration_ns: \d+,
        event: "root",
        properties: [],
    },
]"#;
    let _actual = minitrace::util::tree::tree_str_from_span_records(records.lock().clone());
    assert_eq_text!(_expected, &_actual);
}

The log is (warnings removed):

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running integration/main.rs (target/debug/deps/indev_tokio-f7ac6b01bc817bed)
Setup
Running 1 macro expansion tests
    Updating crates.io index

integration/tests/defaults/no-be-no-drop-local.rs - ok

test �[0m�[1mintegration/tests/defaults/no-be-no-drop-local.expanded.rs�[0m ... �[0m�[1m�[31merror
�[0m�[31mTest case failed at runtime.
�[0m
�[0m�[1m�[33mWARNINGS:
�[0m�[33m┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
�[0m�[31m
�[0m�[31mthread 'main' panicked at 'assertion failed: `(left == right)`
�[0m�[31m  left: `0`,
�[0m�[31m right: `1`', /home/hedge/src/minitrace-rust/src/util/tree.rs:213:9
�[0m�[31mnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
�[0m�[31m┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
�[0m


thread 'main' panicked at '1 of 1 tests failed', /home/hedge/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/trybuild-1.0.61/src/run.rs:100:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: test failed, to rerun pass `--test indev-tokio`

[taqtiqa-mark]

If I understand the post v0.4.1 setup correctly... a semi-dumb helper script is to be replaced by a more sophisticated helper.

Specifically, something like

    let _actual = normalize_spans(records.lock().clone());
    assert_eq_text!(_expected, &_actual);

is to be replaced by

    assert_eq!(
        tree_str_from_span_records(collected_spans.lock().clone()),
        expected_graph
    );

where normalize_spans is

pub fn normalize_spans<R, S>(records: R) -> std::string::String
where
    S: Sized,
    R: AsRef<[S]> + std::fmt::Debug,
{
    let pre = format!("{records:#?}");
    let re1 = regex::Regex::new(r"begin_unix_time_ns: \d+,").unwrap();
    let re2 = regex::Regex::new(r"duration_ns: \d+,").unwrap();
    let int: std::string::String = re1.replace_all(&pre, r"begin_unix_time_ns: \d+,").into();
    let norm: std::string::String = re2.replace_all(&int, r"duration_ns: \d+,").into();
    norm
}

While the more intelligent and sophisticated code path starts from tree_str_from_span_records.

The advantage of the simplicity of normalize_spans is that it stays out of the way in situations like that reported here.

I'm not arguing for tree_str_from_span_records to be replaced by normalize_spans.
I am arguing for normalize_spans to be accepted in PR #127.

[taqtiqa-mark]

Voided by PR #127 rejection.