Background: #27558 (comment)
Async Hooks tests that verify that async resource graph – specifically test/async-hooks/test-graph.http.js – are being flaky with a low probability. We suspect this is due to the verifyGraph improvements in #27477.
Async Hooks exposes a lot of internal details, and in this case it ends being sensitive to the fact that for optimization and implementation details reasons we may occasionally (1 in 1000 in this case) create an async resource graph that the test originally expected.
IMO, we shouldn't have strict expectations on the structure of the async resource graph – there is a lot of implementation detail that is captured hence. The stricter check for expected types added as part of #27477 may end up being more problematic in the long term, IMO. At the least we should default to non-strict matching and use strict matching where the test-cases explicitly calls for it.
/cc @Flarna thoughts?
Background: #27558 (comment)
Async Hooks tests that verify that async resource graph – specifically
test/async-hooks/test-graph.http.js– are being flaky with a low probability. We suspect this is due to theverifyGraphimprovements in #27477.Async Hooks exposes a lot of internal details, and in this case it ends being sensitive to the fact that for optimization and implementation details reasons we may occasionally (1 in 1000 in this case) create an async resource graph that the test originally expected.
IMO, we shouldn't have strict expectations on the structure of the async resource graph – there is a lot of implementation detail that is captured hence. The stricter check for expected types added as part of #27477 may end up being more problematic in the long term, IMO. At the least we should default to non-strict matching and use strict matching where the test-cases explicitly calls for it.
/cc @Flarna thoughts?