Repository navigation
test: investigate flaky - parallel/test-readline-interface #14674
Description
Activity
If somebody has the time, it might be helpful to insert a couple debug statements to check the order in which events happen and then kick of a stress test until this reproduces. Or maybe just increasing the timeouts/using
platformTimeoutmight work?I support use
platformTimeout, 200ms and 500ms maybe too short for raspbian parallel test.It's flaky even if I eliminate all the timers etc. and just have a test that looks like this:
'use strict'; const common = require('../common'); const assert = require('assert'); const readline = require('readline'); const internalReadline = require('internal/readline'); const EventEmitter = require('events').EventEmitter; const inherits = require('util').inherits; const { Writable, Readable } = require('stream'); function FakeInput() { EventEmitter.call(this); } inherits(FakeInput, EventEmitter); FakeInput.prototype.resume = () => {}; FakeInput.prototype.pause = () => {}; FakeInput.prototype.write = () => {}; FakeInput.prototype.end = () => {}; [false].forEach(function(terminal) { { const fi = new FakeInput(); const rli = new readline.Interface( { input: fi, output: fi, terminal: terminal } ); const expectedLines = ['foo', 'bar', 'baz', 'bat']; let callCount = 0; rli.on('line', function(line) { assert.strictEqual(line, expectedLines[callCount]); callCount++; }); expectedLines.forEach(function(line) { fi.emit('data', `${line}\r`); fi.emit('data', '\n'); }); assert.strictEqual(callCount, expectedLines.length); rli.close(); } });
Running it with this:
tools/test.py -j 96 --repeat 96 test/parallel/test-readline-interface.js… still shows failures like this:
AssertionError [ERR_ASSERTION]: '' === 'bar'This means that
lineevents are being emitted but with the data erroneously set to an empty string.The question is: Is this a feature (under resource constraints, stuff starts getting dropped) or is it actually a bug in
readlinebecause the data should never be dropped?The question is: Is this a feature (under resource constraints, stuff starts getting dropped) or is it actually a bug in readline because the data should never be dropped?
@nodejs/streams maybe?
@Trott I don’t think data is getting dropped, it’s that the delay between processing
\rand\nis so long thatreadlinethinks they are actually separate line endings.I do think it’s problematic that this happens even for synchronously emitted input. Maybe we should be using
process.binding('timer_wrap').Timer.now()instead ofDate.now()?I do think it’s problematic that this happens even for synchronously emitted input. Maybe we should be using process.binding('timer_wrap').Timer.now() instead of Date.now()?
@addaleax Brilliant. That doesn't solve all the test's problems, but it solves most of them (and the primary remaining issue looks like it was solved by @Azard in another PR so we're really close...).
15 remaining items
- added 3 commits that reference this issue
on Aug 10, 2017 - added a commit that references this issue
on Sep 19, 2017 - added a commit that references this issue
on Feb 4, 2018 - added a commit that references this issue
on Feb 7, 2018 - added a commit that references this issue
on Apr 13, 2018 - added a commit that references this issue
on May 8, 2018
masterpi1-raspbian-wheezyRefs: #13497
https://ci.nodejs.org/job/node-test-binary-arm/9466/RUN_SUBSET=5,label=pi1-raspbian-wheezy/
/cc @nodejs/platform-arm @addaleax @jasnell @Azard @princejwesley