[SERVER-35154] Exceptions that escape a ScopedThread should fail the test Created: 22/May/18  Updated: 08/Jan/24  Resolved: 19/Sep/18

Status: Closed
Project: Core Server
Component/s: Shell, Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.1.4

Type: Improvement Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Max Hirschhorn
Resolution: Fixed Votes: 1
Labels: tig-qwin-eligible
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-37126 Invoke runSafely for all external imp... Closed
Duplicate
is duplicated by SERVER-36402 ScopedThread's join() method should t... Closed
Problem/Incident
causes SERVER-38838 Early failure in JS file load trigger... Closed
Related
related to SERVER-35113 Stable timestamp does not advance if ... Closed
related to SERVER-35160 ScopedThreads should automatically in... Closed
Backwards Compatibility: Minor Change
Sprint: TIG 2018-09-24
Participants:
Story Points: 5

 Description   

If you start a ScopedThread in a test and it throws an exception, that exception is swallowed and does not error the test, even if the main test thread calls join() and returnData() on the ScopedThread.
This can lead to subtle problems with tests, and issues where tests are broken and no longer testing what they are supposed to, but no one notices.



 Comments   
Comment by Githook User [ 19/Sep/18 ]

Author:

{'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}

Message: SERVER-35154 Propagate JS exceptions through ScopedThread#join().

This makes it so that if the ScopedThread exited due to an uncaught
JavaScript exception, then calling .join() or .returnData() on it throws
a JavaScript exception with the error message and stacktrace intact.
Branch: master
https://github.com/mongodb/mongo/commit/f43ea7a6bb2a6c44f91506c32004241d3cbb24ae

Comment by Spencer Brody (Inactive) [ 22/May/18 ]

Yeah, it'd be nice if developers didn't have to remember to check hasFailed() any time they write a test that uses ScopedThread. Looking through our existing tests, the vast majority of the ones that use ScopedThread are not currently checking hasFailed anywhere.

Comment by Mira Carey [ 22/May/18 ]

Right now I think the contract for checking thread failure is invoking hasFailed() on the thread (which is what the fsm tests do to check).

Now that we have better exception/status convertability, I wouldn't be against making a version of thread (or cutting over hard if that seems advised) which throws on returnData() if the other thread exited with an exception.

Generated at Thu Feb 08 04:38:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.