profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/binaryseed/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Vince Foley binaryseed Portland, OR

binaryseed/comopolo 2

Community web app for COMOPOLO, based on the open source El Dorado

binaryseed/docker-elixir 1

Official Docker image for Elixir :whale: :turtle: :rocket:

binaryseed/dotfiles 1

configuration files

binaryseed/321polo 0

Arduino powered countdown timer for bike polo

binaryseed/absinthe 0

GraphQL for Elixir

binaryseed/absinthe_plug 0

Plug support for Absinthe

binaryseed/absinthe_website 0

Source of absinthe-graphql.org

binaryseed/alpine-elixir 0

A Dockerfile based on my alpine-erlang image for Elixir applications

issue commentnewrelic/elixir_agent

Possible impact of DST Root CA X3 expiration next week?

That seems right from what I can tell.. folks running 23.3 or newer should upgrade. Older OTP versions don't seem to be impacted, right?

mattbaker

comment created time in 4 days

push eventabsinthe-graphql/absinthe

Brian Muller

commit sha adf96597a1fac411db9e2ca89dcd85663d331393

Update telemetry dependency to stable ~> 1.0 (#1097)

view details

push time in a month

PR merged absinthe-graphql/absinthe

Update telemetry dependency to stable ~> 1.0

There were no changes in the Telemetry 1.0.0 release - but it does represent the first "stable" version of the API.

Matches dataloader requirements update.

+1 -1

1 comment

1 changed file

bmuller

pr closed time in a month

pull request commentabsinthe-graphql/absinthe

Update telemetry dependency to stable ~> 1.0

Thanks!

bmuller

comment created time in a month

pull request commentbeam-telemetry/cowboy_telemetry

Require telemetry ~> 1.0

Added you as an owner on hex! Changed the version in https://github.com/beam-telemetry/cowboy_telemetry/commit/496fcc5bf021a3135928138eb61826771d739a39

josevalim

comment created time in a month

release beam-telemetry/cowboy_telemetry

v0.4.0

released time in a month

created tagbeam-telemetry/cowboy_telemetry

tagv0.4.0

Telemetry instrumentation for Cowboy

created time in a month

push eventbeam-telemetry/cowboy_telemetry

Vince Foley

commit sha 496fcc5bf021a3135928138eb61826771d739a39

Bump version 0.4.0

view details

push time in a month

push eventbeam-telemetry/cowboy_telemetry

José Valim

commit sha a13a28b562928f31b27817817b2868733c1116d8

Require telemetry ~> 1.0 (#9)

view details

push time in a month

delete branch beam-telemetry/cowboy_telemetry

delete branch : josevalim-patch-1

delete time in a month

create barnchbinaryseed/elixir_agent

branch : empty-sdk-payload

created branch time in a month

release absinthe-graphql/absinthe

v1.6.5

released time in 2 months

created tagabsinthe-graphql/absinthe

tagv1.6.5

The GraphQL toolkit for Elixir

created time in 2 months

push eventabsinthe-graphql/absinthe

Vince Foley

commit sha f517348a7ccf6b796e4714b116d9a9420a4e10ac

Bump version 1.6.5

view details

push time in 2 months

push eventabsinthe-graphql/absinthe

Jerel Miller

commit sha bf88b6a6037343f9a233abef8a88480ec8f25371

Allow interface fields to reference other interfaces (#1089) (#1091) * Allow interface fields to reference other interfaces (#1089) * Quick test assertion fix Co-authored-by: Vince Foley <39946+binaryseed@users.noreply.github.com>

view details

push time in 2 months

PR merged absinthe-graphql/absinthe

Allow interface fields to reference other interfaces (#1089)

Closes #1089

It appears the DSL and the import_sdl differ in how interface types, with fields that themselves interfaces types, are compiled. When creating schemas via the DSL, compilation works as intended. I can create an interface that contains a field that is another interface type. When I do the same via import_sdl, compilation fails because it Absinthe thinks that the interface is not fully adhered to. This attempts to patch that behavior to ensure interface types can have fields that are themselves interfaces.

To ensure this use case is valid according to the GraphQL spec, I created a minimal reproduction of this schema using GraphQL.js to validate whether the SDL or the DSL had the correct behavior. It does indeed appear that interface types are allowed as fields to other interface types.

+94 -0

2 comments

3 changed files

jerelmiller

pr closed time in 2 months

issue closedabsinthe-graphql/absinthe

Possible difference in schema validation between DSL and import_sdl

The basic questions I'm trying to answer are:

  1. Is there really is a discrepancy in schema validation between using import_sdl vs the DSL when using interfaces in a specific way?
  2. If so, which one is right?

I provided a diff with a couple sample test cases in #1088 with details as well as a sample schema that should be representative of the "real one" we're working with internally.

Env

Elixir 1.12.1 PR is using Absinthe master

Expected behavior

It seems like the two modes should agree, but this is a weird case and I'll fully admit it's a bit of a tangle.

Actual behavior

import_sdl will cause a schema validation failure, while expressing what appears to be the same schema using the DSL succeeds.

@jerelmiller — curious if my test case matches what you think you're seeing as well.

closed time in 2 months

mattbaker

push eventjerelmiller/absinthe

Vince Foley

commit sha bd812f1cd149621c3b50e822bb51f16f6d26eb74

Quick test assertion fix

view details

push time in 2 months

PullRequestReviewEvent

Pull request review commentabsinthe-graphql/absinthe

Allow interface fields to reference other interfaces (#1089)

 defmodule Absinthe.Phase.Schema.Validation.ObjectMustImplementInterfaces do     :ok   end +  defp check_covariant(+         %Blueprint.TypeReference.Name{name: iface_name},+         %Blueprint.TypeReference.Name{name: type_name},

Ahh, I suspect the difference between the SDL & DSL is that only SDL currently generates the TypeReference blueprint structs everywhere... DSL winds up with bare-atom identifiers

This is a related note from a while back: https://github.com/absinthe-graphql/absinthe/issues/783

jerelmiller

comment created time in 2 months

PullRequestReviewEvent

issue commentnewrelic/elixir_agent

Release 1.27.5 to hex

Done, sorry for the delay

mhanberg

comment created time in 2 months

issue closednewrelic/elixir_agent

Release 1.27.5 to hex

Hi!

Would you be able to release 1.27.5 to hex.pm?

Thanks!

(I tried to leave this as a comment on #359, but for some reason it was giving me an error saying "You can't comment at this time.")

closed time in 2 months

mhanberg

release newrelic/elixir_agent

v1.27.5

released time in 2 months

release newrelic/elixir_agent

v1.27.4

released time in 2 months

created tagnewrelic/elixir_agent

tagv1.27.5

New Relic's Open Source Elixir Agent

created time in 2 months

push eventnewrelic/elixir_agent

Vince Foley

commit sha 7a48f562492e7273a459500cc5b18711d0e93ee3

Bump version 1.27.5

view details

push time in 2 months

pull request commentnewrelic/elixir_agent

Ensure Task is loaded before running function_exported?/3

Thanks!

mhanberg

comment created time in 2 months

push eventnewrelic/elixir_agent

Mitchell Hanberg

commit sha dbb3cd223b9192e9e3c31507652d171cbace77f0

Ensure Task is loaded before running function_exported?/3 (#359) There can be a race condition when the compiler is evaluating these lines of code, that allow for function_exported? to return false. This is because the Task module hasn't been loaded yet. Running `Code.ensure_loaded?(Task)` before calling `function_exported?` will make sure that we avoid the race condition.

view details

push time in 2 months