Codecov Report

Merging #260 (c9561c4) into master (86f52e9) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #260   +/-   ##
=======================================
  Coverage   78.87%   78.87%           
=======================================
  Files           3        3           
  Lines         303      303           
=======================================
  Hits          239      239           
  Misses         40       40           
  Partials       24       24           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 86f52e9...c9561c4. Read the comment docs.

This PR contains the following updates:

Release Notes

<details> <summary>aws/aws-sdk-go</summary>

v1.38.62

Compare Source

===

Service Client Updates

• service/connect: Updates service API, documentation, and paginators
• service/ec2: Updates service API
  • EC2 M5n, M5dn, R5n, R5dn metal instances with 100 Gbps network performance and Elastic Fabric Adapter (EFA) for ultra low latency
• service/models.lex.v2: Updates service API and documentation
• service/redshift-data: Updates service API and documentation
• service/runtime.lex.v2: Updates service API and documentation

</details>

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box.

This PR has been generated by WhiteSource Renovate. View repository job log here.

Thanks for this! Not sure why it continued building for me, but I can see the error. Merged!

After merging PR https://github.com/nathankellenicki/node-poweredup/pull/130 project can not build from master branch. This fix should be resolve this issue.

Problem

message=Uncaught TypeError: Cannot read property 'offsetTop' of null
source=file:///tmp/.mount_AthensTZzJa8/resources/app.asar/resources/public/js/compiled/renderer.js
Lineno=285
colno=483
error=TypeError: Cannot read property 'offsetTop' of null
``

**Screenshots/Demo**

This doesn't happen consistently, but appears to correspond to being on a page that's not today's page and then double-clicking the calendar icon to get to today's page. It may or may not require having the originating page designated as a shortcut.

**Athens Version**

Athens 1.0.0-BETA.88

@GeraldLoeffler I'm happy that I understood you 😄

However, this should be treated like the other schemas in that directory (server.json, message.json, ...), with agreed-upon filename etc., so that the $ref from the AsyncAPI docs has the same syntax for all bindings:

yes exactly, that was my idea with common.json filename. If we go with tag versioning for bindings - every patch/minor/major version of binding will have separate git tag in repo, then we can still ref to appropriate version, but... writing each time https://raw.githubusercontent.com/asyncapi/bindings/master/http/json_schemas/common.json link can be annoying, so I don't know if it's possible with JSON Ref but having some shortcut for some links like https://raw.githubusercontent.com/asyncapi/bindings/master/http/json_schemas/common.json could be #bindings/http/common etc.

thanks @magicmatatjahu for interpreting my thoughts and discussing them with @derberg ;) : you're right, my concern is that schemas like httpHeader from @derberg 's example should come from the binding spec, to make it much easier for AsyncAPI docs to refer to common protocol headers.

I certainly did not want to propose to

apply it automatically to the AsyncAPI document

but rather to discuss the issue and find an uniform approach for an AsyncAPI document to reference such a common schema of protocol headers.

I do think this could be a solution:

At the moment I can only suggest to have some common data (not only headers) for protocols/bindings inside the bindings repo and make $ref to them like $ref: https://raw.githubusercontent.com/asyncapi/bindings/master/http/json_schemas/common.json#headers

However, this should be treated like the other schemas in that directory (server.json, message.json, ...), with agreed-upon filename etc., so that the $ref from the AsyncAPI docs has the same syntax for all bindings: https://raw.githubusercontent.com/asyncapi/bindings/master/http/json_schemas/common.json#headers`