profile
viewpoint
Blake Williams shabbyrobe I code for fun. I have been known to code for food. I typically work with Go, TypeScript, Python or C. I enjoy Go a lot. I have worked with lots of other stuff.

johannesboyne/gofakes3 203

A simple fake AWS S3 object storage (used for local test-runs against AWS S3 APIs)

shabbyrobe/cachet 20

Cachet - Pluggable Caching for PHP >=5.6

shabbyrobe/amiss 19

PHP Data Mapper and Active Record implementation for MySQL and SQLite

shabbyrobe/go-num 12

Additional numeric types for Go (int128, uint128)

shabbyrobe/go-service 5

Lifecycle management for long-lived goroutines

shabbyrobe/ctrlp-netrw.vim 2

CtrlP plugin for opening netrw in specified directory.

shabbyrobe/fur 2

Command line Gopher Client (RFC1436)

shabbyrobe/gibberdet 2

Go port of rrenaud's gibberish detector

shabbyrobe/go-porter2 2

Performance-oriented fork of the English porter2 stemmer from https://github.com/dchest/stemmer/

shabbyrobe/afero 1

A FileSystem Abstraction System for Go

issue commentRedocly/openapi-cli

Lint incorrectly reports boolean schemas for array items as invalid

This seems to apply to unevaluatedProperties and unevaluatedItems too; the same kind of error is reported.

shabbyrobe

comment created time in a day

issue openedRedocly/openapi-cli

Lint incorrectly reports boolean schemas for array items as invalid

To Reproduce Steps to reproduce the behavior:

  1. Given this .redocly.yaml file None

  2. And this OpenAPI file(s)

<details> <summary>openapi.yml</summary>

openapi: 3.1.0

info:
  title: Bug
  version: 0.0.1
  description: "Bug"
  license:
    name: Unlicensed
    identifier: UNLICENSED
    url: http://invalid

servers:
- description: "yep"
  url: http://invalid

paths:
  /test:
    get:
      operationId: getTest
      summary: Get Test! Foo! Etc!
      responses:
        200:
          description: "200"
          content:
            application/json:
              schema:
                type: array
                prefixItems:
                  - type: "string"
                items: false
        400:
          description: "400"
          content:
            application/json:
              schema: { type: "object" }

</details>

  1. Run this command with these arguments... openapi ...
npx @redocly/openapi-cli lint ~/tmp/oasbug.yml
  1. See error
Expected type `Schema` (object) but got `boolean`

28 |         prefixItems:
29 |           - type: "string"
30 |         items: false
31 | 400:
32 |   description: "400"

Expected behavior This is valid according to Draft 2020-12's test suite

openapi-cli Version(s) What version of openapi-cli are you using? 1.0.0-beta.69

Node.js Version(s) What version of node.js are you using? 16.10.0

created time in 7 days

issue openedRedocly/openapi-cli

A mechanism to intercept and modify `$ref` before resolution

Is your feature request related to a problem? Please describe. I'm trying to intercept and rewrite $ref links as part of a complex bundling workflow involving a library of shared multi-file JSON schema components and several OpenAPI specs (and other non-OpenAPI schemas) that depend on them. The shared schema components have their own bundling processes and workflows that I have some, but not a lot, of influence over.

It's easy enough when referencing the shared schemas from OpenAPI as I can just use a relative filesystem path, but when they refer to each other it's trickier as I have less control and can't really change the id and referencing scheme in those components.

The build infrastructure and schema resources for this project are private and heavily constrained, so they can't easily be deployed, which means the URLs we are using aren't able to be resolved. This is arguably the biggest smell here but it's the hand I've been dealt and I need to play it, sadly.

For instance:

openapi.yml:

lotsOfParentContext:
  $ref: "../../shared/thing.json"

Shared schema thing.json:

{
  "type": "object",
  "properties": {
    "other": {
      "//": "the following URL won't ever resolve to the actual schema, it's used more as a fully qualified namespace identifier",
      "$ref": "https://example.com/shared/other.json"
    }
  }
}

Shared schema other.json:

{"type": "object"}

I had hoped to be able to translate things like fully qualified URLs to local file system paths, for instance:

From: {"$ref": "https://example.com/path/to/standalone/schema.json"}
To:   {"$ref": "/absolute/local/file/path/to/standalone/schema.json"}

Unfortunately I haven't yet found a way to do this (or something like it).

Describe alternatives you've considered I tried to implement this using a preprocessor, but preprocessing seems to happen after $ref resolution. I also tried poking around with the resolve config but that seems more limited to tweaking headers for resolving external URL $refs.

Describe the solution you'd like Maybe something added to plugins that allows the ref resolving step to be intercepted? Or possibly something added to the resolve config section to allow a regex and replacement pattern with backreferences? I'm not particularly fussed, nor familiar enough with the existing code, to have a strong opinion on the actual solution.

Additional context Happy to provide any further details if this request is unclear. Perhaps this is already possible and I'm just missing something.

created time in 8 days

startedskyjake/lagrange

started time in 11 days

startedMasterQ32/kristall

started time in 11 days

startedmatusf/openapi-fuzzer

started time in 15 days

startedagnivade/levenshtein

started time in 19 days

issue commentRedocly/openapi-cli

Implicit 'name' and 'in' properties in 3.1-style reusable headers causes lint errors

Ah yep that makes sense, I missed that "reusable headers" means "reusable response headers". I've switched to using a "reusable header parameter" as you suggest and it lints fine now. The non-reproducible error was because I pasted the wrong output 🤦‍♂️. Thanks for the help, much appreciated!

shabbyrobe

comment created time in 21 days

issue openedRedocly/openapi-cli

Implicit 'name' and 'in' properties in 3.1-style reusable headers causes lint errors

Based on my reading of the OpenAPI 3.1.0 spec, it looks like openapi-cli doesn't correctly handle when headers are defined in /components/headers and referenced in a response.

<details> <summary>Click here for reproducing openapi.yml file</summary>

openapi: 3.1.0

info:
  title: Bug
  version: 0.0.1
  description: "Bug"
  license:
    name: Unlicensed
    identifier: UNLICENSED
    url: http://invalid

servers:
- description: "yep"
  url: http://invalid

components:
  headers:
    Foo-Bar:
      required: true
      description: "Foo bar!"
      schema:
        type: "string"

paths:
  /test:
    get:
      operationId: getTest
      summary: Get Test! Foo! Etc!

      parameters:
      - $ref: "#/components/headers/Foo-Bar"

      responses:
        200:
          description: "200"
          content:
            application/json:
              schema: { type: "object" }
        400:
          description: "400"
          content:
            application/json:
              schema: { type: "object" }

</details>

I get the following errors:

[1] tmp/oasbug.yml:19:7 at #/components/headers/Foo-Bar/in
Property `in` is not expected here.

[2] tmp/oasbug.yml:20:7 at #/components/headers/Foo-Bar/name
Property `name` is not expected here.

According to the spec about header objects (referenced in the components property table), header objects aren't supposed to contain a name or an in, as both are implied from their presence in /components/headers.

From https://spec.openapis.org/oas/v3.1.0#header-object:

The Header Object follows the structure of the Parameter Object with the following changes:

  1. name MUST NOT be specified, it is given in the corresponding headers map.
  2. in MUST NOT be specified, it is implicitly in header.

I've tried adding in: and name: to the shared header, but that causes errors too. I also tried attaching an in: and a name: to the object containing the $ref, but that doesn't silence the errors either.

Expected behavior I'm not 100% sure my reading is right, but I would expect no errors for the above spec (modulo any typos I may have let sneak in there of course)

OpenAPI definition OpenAPI 3.1

openapi-cli Version(s) 1.0.0-beta.67

Node.js Version(s) 16.10.0

created time in 22 days

pull request commentshabbyrobe/grpc-stubs

Fix request iterator type

Thanks for the PR! Could you please share a short snippet demonstrating the issue this was causing you?

ilianovoselov-foodpairing

comment created time in 22 days

push eventshabbyrobe/grpc-stubs

Ilia Novoselov

commit sha 37bc7c3f3f7dc8b57f8c1c1055d3e83edda2ebb4

Fix request iterator type

view details

Blake Williams

commit sha 40388d2e2ba0bd49ab75d0251bb1ac98319db756

Merge pull request #24 from ilianovoselov-foodpairing/fix-request-iterator-type Fix request iterator type

view details

push time in 22 days

pull request commentshabbyrobe/grpc-stubs

server() expects list of ServerInterceptor

Thanks for the fix!

jyggen

comment created time in 22 days

push eventshabbyrobe/grpc-stubs

Jonas Stendahl

commit sha 7782d9a142e004aa266f3ff2205b95a9b41b7252

server() expects list of ServerInterceptor

view details

Blake Williams

commit sha 99e36851c4d9b2d5392ba2b98f78c163e802d911

Merge pull request #23 from jyggen/fix-server-interceptors server() expects list of ServerInterceptor

view details

push time in 22 days

PR merged shabbyrobe/grpc-stubs

server() expects list of ServerInterceptor

The current typehint wants a list of various client interceptors, when in reality it should be a list of ServerInterceptor as per the docs:

interceptors: An optional list of ServerInterceptor objects that observe and optionally manipulate the incoming RPCs before handing them over to handlers. The interceptors are given control in the order they are specified. This is an EXPERIMENTAL API.

+3 -3

0 comment

1 changed file

jyggen

pr closed time in 22 days

startedberstend/puppeteer-extra

started time in a month

issue commentJulian/jsonschema

"TypeError: argument of type 'bool' is not iterable" when unevaluatedProperties present but instance is boolean

Thanks Julian, I'll definitely take a run at that and let you know once I have a PR there on the test repo.

I cloned this repo last night too after robherring's helpful hints but I had all kinds of trouble getting the tests to run using tox. I was getting some cryptic ungooglable error about wheels that nobody else in the world seems to be having 😆. Is there a quick-and-dirty way you can point me to for running the jsonschema repo's test suite quickly as part of a development workflow that doesn't involve the whole tox rigmarole?

shabbyrobe

comment created time in a month

fork shabbyrobe/jsonschema

An implementation of the JSON Schema specification for Python

https://python-jsonschema.readthedocs.io

fork in a month

issue openedJulian/jsonschema

"TypeError: argument of type 'bool' is not iterable" when unevaluatedProperties present but instance is boolean

Here's a minimum reproducer with jsonschema==4.1.2:

import jsonschema

validator = jsonschema.Draft202012Validator({
    "type": ["object", "boolean"],
    "unevaluatedProperties": False,
    "properties": {
        "foo": { "type": "string" },
    },
})

validator.validate(True)

I get the following exception:

Traceback (most recent call last):
  File "bug.py", line 12, in <module>
    validator.validate(instance)
  File "jsonschema-bug/venv/lib/python3.8/site-packages/jsonschema/validators.py", line 248, in validate
    for error in self.iter_errors(*args, **kwargs):
  File "jsonschema-bug/venv/lib/python3.8/site-packages/jsonschema/validators.py", line 224, in iter_errors
    for error in errors:
  File "jsonschema-bug/venv/lib/python3.8/site-packages/jsonschema/_validators.py", line 434, in unevaluatedProperties
    evaluated_property_keys = find_evaluated_property_keys_by_schema(
  File "sonschema-bug/venv/lib/python3.8/site-packages/jsonschema/_utils.py", line 295, in find_evaluated_property_keys_by_schema
    if property in instance and validator.evolve(
TypeError: argument of type 'bool' is not iterable

I wonder if the checks on line 286 and 293 should also consider the type of the instance before acting on it? I would expect the above schema to pass, but even if it shouldn't, this isn't a great error for it to be raising.

created time in a month

startedjarro2783/cxxopts

started time in a month

startedmadler/crcany

started time in 2 months

startedwimpysworld/quickemu

started time in 2 months

startedlvgl/lvgl

started time in 2 months

startedcloudflare/cfssl

started time in 2 months

startedcameron314/concurrentqueue

started time in 2 months

startedSekhan/TheGreatWall

started time in 2 months

startednicokaiser/rpi-audio-receiver

started time in 2 months

push eventexhibitionist-digital/ultra

Blake Williams

commit sha e552905614d9b5663d8455696ca96836b188b0a9

Deno fmt

view details

push time in 2 months

PR opened exhibitionist-digital/ultra

Handle strings as well as Uint8Arrays in body; error if not either.

Note that this presumes we are always building UTF-8, which is a heck of a presumption.

+32 -2

0 comment

1 changed file

pr created time in 2 months

push eventexhibitionist-digital/ultra

Blake Williams

commit sha ce41984f97f98a3ee47636ee4029be2a7bb60ec1

Handle strings as well as Uint8Arrays in body; error if not either. Note that this presumes we are always building UTF-8, which is a heck of a presumption.

view details

push time in 2 months

more