APIDevTools / json-schema-ref-parser / 14413869142

86%

master: 90%

push

github

fix(BREAKING CHANGE): dereference caching to prevent infinite loops on circular schemas (#380)

We've come across an interesting case with one of our customers OpenAPI definitions where due to the amount of circular references they are using it ends up sending `$RefParser.dereference()` into an infinite loop that has unfortunately been causing us some pain.

The following is a video of running the `dereference.circular=ignore` test in this PR without my eventual fix:

https://github.com/user-attachments/assets/077129bd-997a-40b7-aa57-8129bd7df87f

I've killed the process after 20 seconds but we've seen cases where it can run for almost an hour trying to dereference this circular API definition. In investigating this we've identified a couple issues:

1. When dereferencing this specific schema the event loop gets blocked in the process preventing the `options.timeoutMs` check and exception from ever getting hit.
    * We were able to resolve this by adding a supplementary timeout check when the dereference crawler processes each property within an object.
2. The dereference cache isn't being fully taken advantage of.

In investigating the cache issues we noticed a couple more issues:

#### Core issues with `Set` caches

The `Set` objects that are used for `parents` and `processedObjects` don't appear to be fully utilized because these are often setting objects, and `Set` does not do object deuping:

```js
const set = new Set();
set.add({ type: 'string' });
set.add({ type: 'string' });

console.log({ set: Array.from(set), has: set.has({ type: 'string'} )})

> {set: Array(2), has: false}
```

I'm not convinced that any of the `.has()` checks being executed on these stores are currently working and I made an attempt at pulling in [flatted](https://npm.im/flatted)[^1] to create consistent and unique keys off of these values however a couple unit tests broken in unexpected ways and ended up moving on. I would love to spend some more time investigating this ... (continued)

810 of 899 branches covered (90.1%)

Branch coverage included in aggregate %.

16 of 16 new or added lines in 1 file covered. (100.0%)

1644 of 1744 relevant lines covered (94.27%)

26779.09 hits per line