Feature request: Allow nextest to run a script prior to terminating a slow running test

[criccomini]

Motivation

We'd like to be able to get a stack dump of our slow running test before we nextest SIGTERM and kills it. We want nextet to kill the test since it's slow, but it's a bit hard to debug what the state of the test was.

Proposal

After some discussion on slatedb/slatedb#363, we converged on adding a feature to nextest that allows us to run a script prior to slow test termination.

Alternatives

Some alternatives were discussed here:

slatedb/slatedb#363 (comment)

Additional context

No response

[sunshowers]

Thanks! Yeah, this sounds good. I'm in the middle of a significant refactor of the runner code but hope to get to this soon after.

[criccomini]

@benesch wanted to nudge on this-- were you still planning to take a look? I think @sunshowers has wrapped up their work.

[beneschbot]

It's still in my queue but afraid I've been juggling a few too many things last week and this week! Picking this up is still in my queue and I'm hoping to have some time over the holidays, but I'd be happy to tag team this with someone, or have someone else beat me to it.

[benesch]

Heh, whoops, posted that while signed in to my service account.

[criccomini]

NP. No rush, was just checking on status. =) re: tag team, I'm in a similar boat as you. Already behind on some book stuff. :/ So, I'll have to bow out for now.

[benesch]

I would imagine that these scripts would go in the scripts table, and that there's a key in slow-timeout that allows a particular script to be run. Some things to think about: ...

@sunshowers I've taken a stab at answering some of these questions by writing up the hypothetical docs for how this feature should work: https://github.com/nextest-rs/nextest/pull/2018/files. Documentation driven development is one of my favorite ways to do design work—I find there's something about trying to explain how to use a feature that really forces you to think it through—but let me know if you'd prefer a more traditional design conversation/doc format.

I'm going to start prototyping an implementation to match the docs as I have time, but would love any early feedback you have based on the hypothetical docs!