🐢Tests using wrapped rethrowAsync take a very long time.

[calebcordry]

I don't think this is a problem on travis because we increase the timeout limit, but when running tests locally this causes consistent failure on macbook pro.

We have a function that stubs usage of rethrowAsync in tests

amphtml/test/_init_tests.js

Line 375 in d1a7ee5

function preventAsyncErrorThrows() {

This stub eventually calls

amphtml/test/_init_tests.js

Line 380 in d1a7ee5

self.__AMP_REPORT_ERROR(error);

In these stubed tests self.__AMP_REPORT_ERROR() is a ref to

amphtml/src/error.js

Line 150 in d1a7ee5

export function reportError(error, opt_associatedElement) {

In that function we call

amphtml/src/error.js

Line 200 in d1a7ee5

output.call(console, error.stack);

That line of code takes between 2.7 - 3.1 seconds to execute on my laptop!!?!!?

console error here is also stubbed to be a no op

amphtml/test/_init_tests.js

Line 321 in d1a7ee5

consoleErrorStub.callsFake(() => {});

I put some console.times in here to see what was going on, and from the call to the time the NOOP function is executed accounts for the slowness. Unfortunately all the code that is executed in between is part of our external testing packages so I am not sure there is a good fix. Maybe reevalute how we are stubbing things?

If you want to see my "profiling" I have a draft pr here #25724 if you pull those changes and run gulp unit --files=test/unit/test-3p.js --verbose you should be able to repro and see some times being logged.

[calebcordry]

to/ @ampproject/wg-infra cc/ @ampproject/wg-ads

[calebcordry]

Had another thought, maybe this is slow because we are passing around the whole error stack? Just a guess though.

[rsimha]

Nice sleuthing, @calebcordry.

For context, rethrowAsync() was stubbed in order to prevent errors from one test from leaking into a subsequent test (#16916), and console.error was stubbed (via the allowConsoleError mechanism) in order to keep tests honest about runtime errors that may occur during execution (#14336).

I agree we should work on improving how tests can legitimately surface errors. Happy to discuss ideas.

/cc @estherkim who is going to work on overall test reliability.

[calebcordry]

Thanks! I actually like the idea of the stubbed errors etc, but I think this stubception™ might be confusing sinon. Maybe we can convince them to work on their perf for things like this :)

[rsimha]

Resetting assignees since our projects have changed since this was filed. However, I think this is a good area to investigate, since the potential gains can be very high. Bumping to P2.

[rileyajones]

I can't seem to reproduce this issue anymore. If anyone thinks this is still happening, please reopen this ticket.
@dvoytenko @lannka