Ilya Salauyeu

@tyranron I think, that having 2 different behaviours for immediate and postponed retries may be confusing for the users, mostly because reasons behind it aren't obvious. Even we didn't see...

@tyranron out of all upstream implementations only ruby and js have support for retrying scenarios: - [Go's godog authors think that is't a bad feature to implement](https://github.com/cucumber/godog/issues/199#issuecomment-557808499) - [Java's version...

@tyranron > Haven't got it. What do you mean by "re-outputted"? Whole discussion about `re-outputting errors` is linked to [output retries as a separate branch](https://github.com/cucumber-rs/cucumber/issues/212#issuecomment-1118676320). By that I mean, that...

Discussed with @tyranron: 1. Remove `.after(all)` entirely, only `.after(3s)` is allowed. 2. Output reties inside single `Feature`/`Rule` branch. 3. Add `--retry`, `--retry-after` and `--retry-tag-filter` CLI options --- ## Detailed explanation...

@50U10FCA7 @tyranron > For example: Scenarios that will be executing for a long time must be added to execution queue before others. To really solve this issue, in addition to...

@tyranron > How it should help? I don't really grasp your idea. If in the batch there is `Scenario` which is very heavy to execute and other concurrent `Scenario`s may...

@Solonotix I also would argue that `Scenario`s should be distributed across `.feature`-files based on some [domain-specific needs][1], not execution priority. [1]: https://cucumber-rs.github.io/cucumber/current/writing/modules.html#grouping

@tyranron I'm not really sure, if we want this feature. Sounds like it violates [feature coupled step definitions anti-pattern][1]. If you are sure, that we want it, I'm strongly against...

Discussed: We don't want this feature for now, because of mentioned [feature coupled step definitions anti-pattern][1]. Also in `v0.10` preferred way of describing steps is more ergonomic proc-macro attributes (examples...

@theredfish > I think what I want to implement is very similar to `WhichScenarioFn` in `runner::Basic` Yes, this functionality should definitely be in `Runner`. And `WhichScenarioFn` is a good starting...