From @AlexDaniel

Here are some of the modules that are failing on HEAD (but did not fail on 2017.09). At this moment I don't know if the modules are relying on some kind of buggy behavior (which is now fixed?), or if we actually have a regression. If it's not our fault, we still want to make sure that we have tests for these things.

1) WebSocket and better-sched merge

See this issue​: tokuhirom/p6-WebSocket#15

2) Test​::Scheduler and “Push Tap objects down to subscribers”

Also affected​: Concurrent​::Progress, SSH​:LibSSH

See jnthn/p6-test-scheduler#3

3) OO​::Actors and “Start using $*AWAITER in `await` in 6.c”

See jnthn/oo-actors#6

From @AlexDaniel

FWIW I'm not counting 2) and 3) as blockers, but 1) is worth taking a look at. See my comment here​: tokuhirom/p6-WebSocket#15 (comment)
On 2017-10-22 01​:37​:41, alex.jakimenko@​gmail.com wrote​:

Here are some of the modules that are failing on HEAD (but did not
fail on 2017.09). At this moment I don't know if the modules are
relying on some kind of buggy behavior (which is now fixed?), or if we
actually have a regression. If it's not our fault, we still want to
make sure that we have tests for these things.

1) WebSocket and better-sched merge

See this issue​: tokuhirom/p6-WebSocket#15

2) Test​::Scheduler and “Push Tap objects down to subscribers”

Also affected​: Concurrent​::Progress, SSH​:LibSSH

See jnthn/p6-test-scheduler#3

3) OO​::Actors and “Start using $*AWAITER in `await` in 6.c”

See jnthn/oo-actors#6

From @zoffixznet

On Tue, 24 Oct 2017 13​:30​:13 -0700, alex.jakimenko@​gmail.com wrote​:

FWIW I'm not counting 2) and 3) as blockers, but 1) is worth taking a
look at.
See my comment here​:
tokuhirom/p6-WebSocket#15 (comment)
339120879

That looks to be a bug in affinity workers in supply-in-a-sock scenarios.

I made a golfed test[^1] and a hack[^2] that makes the test pass, but isn't enough
to fix the WebSocket module tests, since it applies onto when there's one affinity
worker knocking about and the module likely has more.

Needs a proper fix for the *cause* of the deadlock or a smarter algo for when to
add more affinity workers.

[1] Raku/roast@74445dd
[2] rakudo/rakudo@ce7e544

The RT System itself - Status changed from 'new' to 'open'

From @zoffixznet

On Tue, 24 Oct 2017 21​:48​:16 -0700, cpan@​zoffix.com wrote​:

On Tue, 24 Oct 2017 13​:30​:13 -0700, alex.jakimenko@​gmail.com wrote​:

FWIW I'm not counting 2) and 3) as blockers, but 1) is worth taking a
look at.
See my comment here​:
tokuhirom/p6-WebSocket#15 (comment)
339120879

That looks to be a bug in affinity workers in supply-in-a-sock
scenarios.

I made a golfed test[^1] and a hack[^2] that makes the test pass, but
isn't enough
to fix the WebSocket module tests, since it applies onto when there's
one affinity
worker knocking about and the module likely has more.

Needs a proper fix for the *cause* of the deadlock or a smarter algo
for when to
add more affinity workers.

[1]
Raku/roast@74445dd
[2]
rakudo/rakudo@ce7e544

This is now properly fixed in rakudo/rakudo@59bfa5ab37

As I understand this was the last issue on this ticket, so I'm closing it (tests already went in[^1] and were improved in later commits)

[1] Raku/roast@74445dd

@zoffixznet - Status changed from 'open' to 'resolved'