render empty oauth scopes

[khart-twilio]

see #289

This is my naive attempt to fix the issue. It works but it may have negative side-effects I'm not aware of.

[daveshanley]

Can you add a small test for this, as this new block will reduced coverage, if you pull the project again and update the workflow config (upgraded the codecov action) You should see the coverage on this PR.

[khart-twilio]

I merged the latest change from main branch and ran go test -v -coverprofile cover.out ./... locally and see 100% coverage. In the status on this PR I see 1 workflow awaiting approval, which I assume means you need to approve something before the coverage check can run here, but I'm unfamiliar. I'd appreciate if you clarify for me.

[khart-twilio]

whoops, nevermind I was reading the test output incorrectly. I'll try to figure it out.

[khart-twilio]

@daveshanley One edge case I noticed when testing:

I had:

...
      requestBody:
        content:
          application/json:
            schema:
              type: array
              items:
                type: object
                properties:
                  value:
                    type: null # null isn't allowed here I don't think according to the spec

And with these changes in libopenapi it is now being processed and spit out as

...
                properties:
                  value:
                    type: "ObjectNode"

It doesn't matter for this case since using null was invalid and I changed it to something else, but I'm wondering if it might matter in other places. I'm not familiar with how things like null, true, false come through as yaml.Node object when deserialized and if I'd need to handle these cases in the changes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.62%. Comparing base (0e74598) to head (2ba004f).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #290   +/-   ##
=======================================
  Coverage   99.62%   99.62%           
=======================================
  Files         162      162           
  Lines       16075    16077    +2     
=======================================
+ Hits        16014    16016    +2     
  Misses         56       56           
  Partials        5        5           

Flag	Coverage Δ
unittests	99.62% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[daveshanley]

@daveshanley One edge case I noticed when testing:

I had:

...
      requestBody:
        content:
          application/json:
            schema:
              type: array
              items:
                type: object
                properties:
                  value:
                    type: null # null isn't allowed here I don't think according to the spec

And with these changes in libopenapi it is now being processed and spit out as

...
                properties:
                  value:
                    type: "ObjectNode"

It doesn't matter for this case since using null was invalid and I changed it to something else, but I'm wondering if it might matter in other places. I'm not familiar with how things like null, true, false come through as yaml.Node object when deserialized and if I'd need to handle these cases in the changes.

I have no idea where ObjectNode is coming from. It's not part of libopenapi

Because I have no idea, let's just proceed, if someone else finds this issue then we can investigate further.