fix(oas): user data + server variable quirks

[kanadgupta]

🚥 Resolves RM-9110

🧰 Changes

This PR fixes two interwoven issues related to construction of server variable data.

Issue 1: User Data Payload Retrieval

If a user data payload has a keys array, our oas.defaultVariables() function will look in there but fail to properly retrieve any data from the top level of that payload.

For example, take the following the server variables definition:

{
  "url": "https://{name}.example.com:{port}/{basePath}",
  "variables": {
    "name": { "default": "demo" },
    "port": { "default": "443" },
    "basePath": { "default": "v2" }
  }
}

And say the user payload looks like this:

{
  "name": "owlbert",
  "keys": [
    {
      "apiKey": "test1"
    }
  ],
  "port": "8000"
}

Because of a quirk in our getUserVariable helper, the presence of that keys array in the user data prevents us from using that top-level data at all. The resulting URL is https://demo.example.com:443/v2 when it should be https://owlbert.example.com:8000/v2.

This was a one-liner fix in 6e89c47 and I also added some test coverage in 366ffed 😌

Issue 2: Server Variable Data Precedence in oas.url()

Quick background

Once I figured out the solution to issue 1 above, I noticed the following bug — when you're logged in and you have user data populating your server variables, editing the server variables won't update the code sample:

CleanShot.2024-03-21.at.18.38.31-trimmed.mp4

Isolating the issue

After going down a crazy rabbit hole, I discovered the root issue was with how we use oas.url() to construct the URL in the auto-generated code snippet in our reference section.

For starters, we call oas-to-snippet to generate the snippet, which then invokes oas-to-har:

oas/packages/oas-to-snippet/src/index.ts

Line 81 in 77ba97d

const har = opts.harOverride || generateHar(oas, operation, values, auth);

Once we're in oas-to-har, we invoke oas.url() to construct the resulting URL:

oas/packages/oas-to-har/src/index.ts

Line 277 in 77ba97d

url: `${oas.url(formData.server.selected, formData.server.variables)}${operation.path}`.replace(/\s/g, '%20'),

The issue itself

There are essentially three sources for these variable values that we need to deal with (in order of lowest to highest precedence):

1. Default values, as defined in the OpenAPI definition itself
2. User data, as defined via JWT
3. Current state data, a.k.a. whatever the end user manually writes into their API reference section

The problem is we were prioritizing 2 over 3. This PR reworks some logic related to oas.url() to fix that, see 9fbea61 😮‍💨

🧬 QA & Testing

For all of this, the new test cases provide a great visualization of the changes and expected behaviors. That and all the existing test coverage passes, so hopefully we should be in good shape!

[erunion]

assuming this fix is for something pretty serious, did you want to try to backport it to the current version of oas we're running in prod?

[kanadgupta]

@erunion I'm open to it — maybe #842 also? anything else? cc: @darrenyong

[darrenyong]

yep, sounds good!