primordic/IssueDupesLite huggingface dataset:
Repository: goss-org/goss

Issue #149: GOnetstat/port resource fail to notice net.ipv6.bindv6only - validation fails when dual mode ipv4/6 port is available
Created: 2016-09-14T01:27:57Z
When sysctl net.ipv6.bindv6only is 0 (the default value), ports shown as tcp6 in netstat output are may be actually listening on both protocols. If I start with a Goss check like this:
port:
  tcp:12345:
    listening: true

And I then create a simple container, exposing a port on all interfaces (ipv4 and ipv6), like so:
$ docker run -d -p 12345:80 --name goss-test nginx

Then I'll find that I can correctly use the listening port via ipv4:
$ nc -z 127.0.0.1 12345 ; echo $?
0

However, goss will not validate the port correctly:
$ goss validate
F

Failures/Skipped:

Port: tcp:12345: listening:
Expected
    <bool>: false
to equal
    <bool>: true

Total Duration: 0.016s
Count: 1, Failed: 1, Skipped: 0

What this boils down to is: goss is ensuring netstat's output, not the actual state of the ports.
Isn't netstat generally deprecated in favour of ss, because ss does a better job of not confusing the user in ipv6 situations like this one? e.g.
$ sudo ss -lapn | grep 12345
tcp    LISTEN     0      512                   :::12345                :::*      users:(("docker-proxy",25454,4))

versus
$ sudo netstat -lapn | grep 12345
tcp6       0      0 :::12345                :::*                    LISTEN      25454/docker-proxy

(ss is more correct; this is a tcp port, not a tcp6 specific one)

Duplicate issue #215: dgoss add port in tomcat images shows not listening even though the port is listening
Created: 2017-03-28T07:33:24Z
docker pull tomcat:alpine
dgoss edit -p 8080:8080 tomcat:alpine

INFO: Starting docker container
INFO: Container ID: de8ef54c
INFO: Run goss add/autoadd to add resources
/goss # goss add port 8080
Adding Port to './goss.yaml':

tcp:8080:
  listening: false
  ip: []


/goss # netstat -tlnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 :::8080                 :::*                    LISTEN      1/java
tcp        0      0 ::ffff:127.0.0.1:8005   :::*                    LISTEN      1/java
tcp        0      0 :::8009                 :::*                    LISTEN      1/java
/goss # wget http://localhost:8080
Connecting to localhost:8080 (127.0.0.1:8080)
index.html           100% |*******************************| 11230   0:00:00 ETA
/goss #

Closing comment (2017-03-29T19:02:36Z): I'm gonna close this as a duplicate of #149 so we have one location to track this
Repository: goss-org/goss

Issue #338: Process module: validate that a process is running under a user account
Created: 2018-03-24T15:27:53Z
I would like to validate that some application is not running as root. Is there currently a way to check this? Otherwise I suggest extending the process module:
process:
  chrome:
    # required attributes
    running: true
    # optional attributes
    user: root

Duplicate issue #373: user for running process
Created: 2018-08-11T23:42:57Z
Is there support for checking the user a process is running as ?
Thanks

Closing comment (2019-08-22T15:03:26Z): Duplicate of #338.
Repository: goss-org/goss

Issue #334: goss doesn't support semantic versioning for custom rpms
Created: 2018-03-20T22:01:16Z
Hi,
Its nice to use your tool.
But there is an bug i have found it doesn't support custom versioing of rpms
lets take an example
Here is my goss.yaml
{code}
package:
custom-service:
installed: true
versions:
- "5.37.0-201709220549.68d18f9"
service:
custom-service:
enabled: true
running: true
{code}
when I try to validate it fails
...F
Failures/Skipped:
Package: custom-service: version:
Expected
<[]string | len:1, cap:1>: ["5.37.0"]
to contain element matching
: 5.37.0-201709220549.68d18f9
Total Duration: 0.044s
Count: 4, Failed: 1, Skipped: 0

Duplicate issue #920: Semver package check did not work with alpine packages
Created: 2024-05-22T14:53:47Z
Describe the bug
Semver versions check for package doesn't work with alpine packages. The actual package version for curl is 8.5.0-r0
How To Reproduce
matching:
  curl:
    content:
      - 8.5.0-r0
    matches:
      and:
        - contain-element:
            semver-constraint: ">=8.5.0"

>=8.4.0 is green. it seams that -r0 is interpreted as release candidate
Expected Behavior
valid
Actual Behavior
error
Environment:

Version of goss 0.4.7
OS/Distribution version (if applicable) alpine

Closing comment (2024-06-04T16:39:30Z): A little bit related to:

#334
Repository: goss-org/goss

Issue #925: Final steps to new documentation
Created: 2024-06-04T17:10:48Z
The documentation was migrated to readthedocs.io
This seems to work:


stable: https://goss.readthedocs.io/en/stable/containers/kubernetes/



latest (after PR #904) https://goss.readthedocs.io/en/latest/containers/kubernetes/



 fix problems with PR docs preview
(example #924 , error 404 https://goss--924.org.readthedocs.build/en/924/)


 redirect https://goss.rocks to https://goss.readthedocs.io/en/stable/ (except https://goss.rocks/install)


 update links to documentation in README.md


related to:

#856

I do not know the solution for docs preview. Perhaps a settings in readthedocs.io

Duplicate issue #1014: Links in documentation are broken
Created: 2025-01-22T20:24:43Z
Describe the bug

Currently the docs contain several links to https://goss.rocks. Those are all broken.
I assume most should be replaced with the appropriate links to https://goss.readthedocs.io/en/stable/
I'm happy to provide a PR to fix those if linking them to readthedocs.io is the prefered solution 😄
Broken Links:
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L108-L109
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L164
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L196
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L203
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L209-L211
https://github.com/goss-org/goss/blob/master/README.md?plain=1#L346
https://github.com/goss-org/goss/blob/master/docs/gossfile.md?plain=1#L106
https://github.com/goss-org/goss/blob/master/docs/gossfile.md?plain=1#L115
https://github.com/goss-org/goss/blob/master/.github/ISSUE_TEMPLATE/feature_request.md?plain=1#L14
https://github.com/goss-org/goss/blob/master/.github/CONTRIBUTING.md?plain=1#L38

Closing comment (2025-03-14T21:40:58Z): Related to:

#925
Repository: gpustack/gpustack

Issue #1122: Manually setting four graphics cards can run the model, but setting six graphics cards prompts' No suitable workers'
Created: 2025-02-06T15:01:27Z
Manually setting four graphics cards can run the model, but setting six graphics cards prompts' No suitable workers'
Select four 4070

Select six 4070

Duplicate issue #1122: Manually setting four graphics cards can run the model, but setting six graphics cards prompts' No suitable workers'
Created: 2025-02-06T15:01:27Z
Manually setting four graphics cards can run the model, but setting six graphics cards prompts' No suitable workers'
Select four 4070

Select six 4070

Closing comment (2025-02-11T12:54:35Z): The issue of being unable to use more RPC servers has been resolved in main. The occasional crashes of RPC server is tracked in #1122
Repository: gpustack/gpustack

Issue #978: GPUStack deployed in WSL2 successfully, but the worker initialization failed
Created: 2025-01-15T04:27:52Z
Describe the bug

Failed to initialize worker in WSL2
Steps to reproduce
操作系统名称	Microsoft Windows 11 专业工作站版
版本	10.0.26100 版本 26100

Install WSL2 in Win 11.
Install CUDA in WSL2 with following commands.

wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-6

Install GPUStack with curl -sfL https://get.gpustack.ai | sh -s -

Result

Expected behavior




Environment

GPUStack version: 0.4.1
OS: Linux version 5.15.167.4-microsoft-standard-WSL2 (root@f9c826d3017f) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37)  SMP Tue Nov 5 00:21:55 UTC 2024
GPU: NVIDIA GeForce RTX 2060 with Max-Q Design

Additional context
Add any other context about the problem here.

Duplicate issue #1297: Add WSL Path for nvidia-smi Detection
Created: 2025-02-21T16:58:06Z
In WSL, the default user can execute nvidia-smi, but the root user does not have the environment variable set.
When installed via a script, the GPU detection fails to correctly detect the GPU. This needs improvement to ensure that the nvidia-smi path is correctly detected.
Add WSL path for nvidia-smi detection: /usr/lib/wsl/lib/nvidia-smi

Closing comment (2025-02-21T17:57:48Z): Related to: #978
Repository: gpustack/gpustack

Issue #1121: Calculate resources based on the customized -ngl parameter
Created: 2025-02-06T05:28:00Z
Is your enhancement related to a problem? Please describe.

The -ngl parameter has been set, but the computing resources are still calculated based on full offload. Additionally, the UI is unable to display the label of CPU offload



Describe the solution you'd like

If the -ngl is set manually, the resources will be calculated based on the set value.

Duplicate issue #1257: Offloading number of layers to GPU wrongly reflected in UI
Created: 2025-02-19T09:46:42Z
When adding backend parameter --gpu-layers=4, its not reflected properly in UI. UI is showing inversed value of offloaded layers.

Steps to reproduce

Deploy model with CPU-GPU offloading with option --gpu-layers=4

Result
UI is displaying inverted number of layers. Instead on 4 number of layers displayed for GPU, 4 layers are displayed for CPU
Expected behavior
$ number of layers displayed for GPU
Environment

GPUStack version: 0.5.0
OS: Linux Rocky 8.10
GPU: Tesla T4

Additional context

Closing comment (2025-02-19T09:52:10Z): Related to #1121
Repository: gpustack/gpustack

Issue #1082: The NPU and MUSA images are missing audio packages
Created: 2025-01-23T04:14:21Z
The NPU and MUSA images are missing audio packages.

Duplicate issue #1504: Failed to run the vox-box server: [Errno 2] No such file or directory: '/usr/local/python3.10/bin/vox-box'
Created: 2025-03-20T10:16:40Z
Describe the bug
I encountered missing environment dependencies while deploying the STT model using the latest Docker image with gpustack version 0.5.1.
Steps to reproduce

deploy model is faster-whisper-large-v3


Result
2025-03-20T10:02:44+00:00 - gpustack.worker.backends.vox_box - INFO - Starting vox-box server
2025-03-20T10:02:44+00:00 - gpustack.worker.backends.vox_box - ERROR - Failed to run the vox-box server: [Errno 2] No such file or directory: '/usr/local/python3.10/bin/vox-box'
Expected behavior
deploy succeed
Environment

GPUStack version: 0.5.1
OS: EulerOS 2.0 (SP10)
GPU: ascend 910b

Additional context
docker image: gpustack/gpustack:latest-npu

Closing comment (2025-03-20T12:54:12Z): Related to: #1082
Repository: gpustack/gpustack

Issue #861: WARNING - RPC server for GPU 0 is not running, pid 20568, restarting
Created: 2024-12-29T13:16:12Z
I'm encountering an error on my server A (192.168.0.199) and I'm not sure which command to use to start the necessary process. I need your guidance. Thank you.

Duplicate issue #1086: GPUStack failed to start after changing timezone in Linux
Created: 2025-01-23T15:28:29Z
Describe the bug
Install GPUStack with the Linux script, and change the timezone from UTC to Asia/Shanghai.  GPUStack failed to start after this and couldn't recover after reverting the change.
Steps to reproduce


Environment

GPUStack version: v0.5.0
OS: Linux

Closing comment (2025-02-06T03:11:06Z): Hi @BenjaminX
The issue with timezone has been fixed in main.
However, as shown in the screenshot, there is still an issue with the rpc server constantly restarting, which is being tracked in #861.
Additionally, the issue of the GPUStack service constantly restarting could not be reproduced. If this issue still exists, please feel free to reopen this issue or file a new one, and provide the following additional information:

sudo dmesg | grep gpustack
sudo dmesg | grep llama-box
sudo journalctl -u gpustack.service -n 50
cat /var/lib/gpustack/log/rpc_server/gpu-0.log or the logs of the rpc server in the custom data-dir path.
Repository: gpustack/gpustack

Issue #1300: Worker failed to start with a host name contains Chinese characters
Created: 2025-02-21T21:45:05Z
Result

Expected behavior

Environment

GPUStack version: v0.5.1
OS: windows 11

Duplicate issue #1352: ERROR - Failed to inject allocated resources: (401, 'Unknown', '{"detail":"Invalid authentication credentials"}' - No GPU detected.
Created: 2025-02-27T06:13:15Z
单机三卡配置，Windows11系统。按照官方文档使用脚本安装。进入网页管理端看不到本机GPU。
启动窗口能看到报错，具体详见log文件。
gpustack.log
RPC服务日志运行命令后无反应。


GPU驱动与CUDA都已经正常安装且为最新版本，C++环境也已经是最新版本。

Closing comment (2025-02-27T06:19:16Z): 2025-02-27T11:57:30+08:00 - gpustack.worker.worker_manager - ERROR - Failed to register worker: (401, 'Unknown', '{"detail":"Invalid authentication credentials"}')

May be related to #1300. Can you run with --worker-name some-alphanumeric-name to address the naming issue?
Repository: gpustack/gpustack

Issue #1705: Compatibility checks enhancements for GPUStack workers
Created: 2025-04-11T05:25:23Z
Is your enhancement related to a problem? Please describe.



For vLLM distributed inference, manually specifying GPUs (not from gpustack server) does not verify whether Ray is enabled.


It does not verify whether the worker is configured with the hf-token.

Duplicate issue #1635: Manual GPU selection compatibility check issues
Created: 2025-04-03T08:46:04Z
Describe the bug


When selecting a non-NVIDIA GPU for an audio model, there is no prompt for incompatibility.
When selecting a GPU on a non-Linux node for vLLM distributed inference, there is no prompt for incompatibility.
When distributed inference with vLLM selects a node that does not have ray enabled, the prompt is incorrect.


Environment

GPUStack version: main 95916b8

Closing comment (2025-04-11T05:28:33Z): GPUStack version: main 8bed348
Issue 1: pass
Issue 2: pass
Issue 3: pass, but currently, it does not check whether the remote worker has enabled ray, tracked by #1705
Repository: graphql-java/graphql-java

Issue #1764: Allow interfaces to implement other interfaces
Created: 2020-01-20T04:14:55Z
graphql/graphql-spec#373

Duplicate issue #1866: Add support for Intermediate Interfaces & Generic Utility Types
Created: 2020-04-17T18:15:23Z
Add support interfaces extending other interfaces as described in the spec here:
graphql/graphql-js#2084
And already implemented in graphql-js 15:
https://dev.to/mikemarcacci/intermediate-interfaces-generic-utility-types-in-graphql-50e8

Closing comment (2020-04-17T21:16:32Z): This is a duplicate of #1764
Repository: graphql-java/graphql-java

Issue #498: Error object should have path field to  conform to spec
Created: 2017-06-14T12:47:55Z
http://facebook.github.io/graphql/#sec-Errors says

If an error can be associated to a particular field in the GraphQL result, it must contain an entry with the key path that details the path of the response field which experienced the error. This allows clients to identify whether a null result is intentional or caused by a runtime error.
This field should be a list of path segments starting at the root of the response and ending with the field associated with the error. Path segments that represent fields should be strings, and path segments that represent list indices should be 0‐indexed integers.

Currently this is not in place.
A PR nearly added this but its not quite right since it needs to be a list of path segments re: #304
The spec says :
"path": [ "hero", "heroFriends", 1, "name" ]

Duplicate issue #505: GraphQLError is missing support for path field 
Created: 2017-06-15T19:43:51Z
Today, GraphQLError only supports the required message field, optional locations field, and optional additional custom field(s). It is missing the path field, which is required when applicable.
From the GraphQL spec: https://facebook.github.io/graphql/#sec-Errors

If an error can be associated to a particular field in the GraphQL result, it must contain an entry with the key path that details the path of the response field which experienced the error. This allows clients to identify whether a null result is intentional or caused by a runtime error.
This field should be a list of path segments starting at the root of the response and ending with the field associated with the error. Path segments that represent fields should be strings, and path segments that represent list indices should be 0‐indexed integers. If the error happens in an aliased field, the path to the error should use the aliased name, since it represents a path in the response, not in the query.
...
The response might look like:
{
  "errors": [
    {
      "message": "Name for character with ID 1002 could not be fetched.",
      "locations": [ { "line": 6, "column": 7 } ],
      "path": [ "hero", "heroFriends", 1, "name" ]
    }
  ],
  "data": {
    "hero": {
      "name": "R2-D2",
      "heroFriends": [
        {
          "id": "1000",
          "name": "Luke Skywalker"
        },
        {
          "id": "1002",
          "name": null
        },
        {
          "id": "1003",
          "name": "Leia Organa"
        }
      ]
    }
  }
}
If the field which experienced an error was declared as Non-Null, the null result will bubble up to the next nullable field. In that case, the path for the error should include the full path to the result field where the error occurred, even if that field is not present in the response.

Closing comment (2017-06-15T22:46:45Z): Yes this is correct.  There is a PR in the works for this : #499
Thanks for reporting
I am closing this as a duplicate of #498
Repository: graphql-java/graphql-java

Issue #303: How get selectionSet from DataFetchingEnvironment if selection is FragmentSpread
Created: 2017-01-18T07:15:49Z
DataFetchingEnvironment.fields has information of selected fields.
But when I run below query, I can't find a way to know the field selectionSet at emplPositionClasses field. Because it is explicit defined fragment, so the instance of selection in emplPositionClasses selectionSet is FragmentSpread. and there is no methods to get selectionSet on FragmentSpread.
For the other two type of selection, Field and InlineFragment, there are methods to get selectionSet, so inline fragment has no issue.
the field emplPositionClasses type is EmplPositionClassConnection
query {
  mantle {
    emplPositionClasses {
    	...EmplPositionClassesFragment
    }
  }
}

fragment EmplPositionClassesFragment on EmplPositionClassConnection {
  edges {
    node {
      id
      emplPositionClassId
      title
      description
    }
  }
}

So is it reasonable to also add getSelectionSet() method on class FragmentSpread?

Duplicate issue #377: DataFetchingEnvironment should always have a way to get field sub-selection
Created: 2017-04-16T12:34:33Z
Currently, DataFetchingEnvironment has no way to fetch only the required fields if the query uses fragments.
DataFetchingEnvironment#getFields currently has populated SelectionSet only for Field and InlineFragment, while it is always blank for Fragment. Additionally, fragment definitions are inaccessible as they're only kept in ExecutionContext.

Closing comment (2017-05-02T08:46:06Z): Ah, perfect, this has actually been solved already! Thanks for the explanations @bbakerman and @apottere !
And this issue is basically just a duplicate of #303  so I'll close it.
Repository: graphql-java/graphql-java

Issue #427: Null literal is unsupported
Created: 2017-05-12T08:15:59Z
currently in graphql-java we can't distinguish between provided nulls and unprovided values,
even worse - the query just fails
see the official graphql pr here
graphql/graphql-spec#83

Duplicate issue #74: Empty List of String scalars results into list with one null element
Created: 2016-01-25T09:56:07Z
When doing a mutation requests the relay way with an input object type with the following schema:
{
          "kind": "INPUT_OBJECT",
          "name": "AddFriendRequest",
          "description": null,
          "fields": null,
          "inputFields": [
            {
              "name": "clientMutationId",
              "description": null,
              "type": {
                "kind": "SCALAR",
                "name": "String",
                "ofType": null
              },
              "defaultValue": null
            },
            {
              "name": "hobbies",
              "description": null,
              "type": {
                "kind": "LIST",
                "name": null,
                "ofType": {
                  "kind": "SCALAR",
                  "name": "String",
                  "ofType": null
                }
              },
              "defaultValue": null
            }
          ],
          "interfaces": null,
          "enumValues": null,
          "possibleTypes": null
        }

If you do a mutation without any hobbies, on the java side you'll get a ArrayList with one null element. This is highly inconvenient, I would expect the ArrayList to simply be null in this case.

Closing comment (2017-05-13T06:23:05Z): probably related to #427
Repository: graphql-java/graphql-java

Issue #427: Null literal is unsupported
Created: 2017-05-12T08:15:59Z
currently in graphql-java we can't distinguish between provided nulls and unprovided values,
even worse - the query just fails
see the official graphql pr here
graphql/graphql-spec#83

Duplicate issue #432: Provide support in grammar for NULL value
Created: 2017-05-12T22:23:58Z
The reference implementation has support for knowing that a value has deliberately been set to null or is absent.
graphql/graphql-spec#83
We could extend the grammar to allow a NullValue to be captured in syntax eg:
field (arg : null)

The trick then would be how best to tell DataFetchers that the value is null literal versus not present

Closing comment (2017-05-13T05:46:59Z): This is a duplicate of #427
Repository: graphql-java/graphql-java

Issue #468: Support @deprecated directive in IDL
Created: 2017-05-28T00:26:36Z
According to https://github.com/facebook/graphql/pull/90/files#diff-86a7cb172ae1d944ca3719bd848b1d8bR898

GraphQL implementations that support the type system language must provide the
@deprecated` directive when representing deprecated portions of the schema.

Our schema generation code should transfer the deprecated directive into the runtime types and also have it seen by Introspection

Duplicate issue #502: SchemaGenerator does not support @deprecated directive
Created: 2017-06-15T16:37:00Z
It is possible to include a foo: Foo @deprecated(reason: "this is why it's deprecated") directive on a field within a schema IDL. However the isDeprecated and deprecationReasons are null at runtime.
If my understanding is correct, within SchemaGenerator#buildField(BuildContext, TypeDefinition, FieldDefiniton) there should be be some usage of FieldDefinition.getDirectives() to determine if GraphQLFieldDefinition.Builder#deprecated(String) needs to be called.
More broadly, SchemaGenerator doesn't seem to support directives at all.

Closing comment (2017-06-18T00:13:16Z): Closing as duplicate of #468
Repository: graphql-java/graphql-java

Issue #538: graphql 3.0.0 schema generator does not put additional types in the schema
Created: 2017-06-29T09:06:53Z
Given the following
schema {
    query : Query
}

type Query {
    being(id : ID, type : String) : Being
    beings(type : String) : [Being]
}

interface Being {
    id : ID
    name : String
    nameInQuenyan : String
    invitedBy : ID
}


type Ainur implements Being {
    id : ID
    name : String
    nameInQuenyan : String
    invitedBy : ID
    loves : String
}


type Istari implements Being {
    id : ID
    name : String
    nameInQuenyan : String
    invitedBy : ID
    colour : String
}

type Deity implements Being {
    id : ID
    name : String
    nameInQuenyan : String
    invitedBy : ID
    outlook : String
}

The types Istari and Ainur will not being included in the generated schema since they are not referenced at all.  I think this fix is on master but for 3.0.0 is still a problem
It means you cannot write a interface driven schema

Duplicate issue #544: Interface subtypes in IDL disappear
Created: 2017-07-03T13:40:22Z
if I define subtypes to an interface in IDL they disappear from schema.getAllTypesAsList() and are not available for queries.
schema {
  query: QueryRoot
}

type QueryRoot {
  products: [Product]
}

interface Product {
  name: String!
}

type SubscriptionPlan implements Product {
  name: String!
  numDays: Int!
}


The workaround, as it seems the types are somehow garbage collected - is to add a reference to them like this (see dummySubscriptionPlan QueryRoot):
schema {
  query: QueryRoot

  dummySubscriptionPlan: SubscriptionPlan # Workaround for type to be available
}

type QueryRoot {
  products: [Product]
}

interface Product {
  name: String!
}

type SubscriptionPlan implements Product {
  name: String!
  numDays: Int!
}


Then the type is available and it works.

Closing comment (2017-07-05T09:50:06Z): This is a duplicate of #538 and is indeed fixed on master
Repository: graphql-java/graphql-java

Issue #1314: Introspection query returns types in arbitrary order
Created: 2018-11-13T10:40:12Z
We store the generated GraphQL schema JSON in our Git repo, as it is consumed by various tools. We have noticed that re-generating the JSON results in different output even when there are no changes in our actual schema. I'm not sure if graphql-java is meant to support deterministic schema JSON generation, but there seem to be lots of LinkedHashMaps/Sets internally, and I can't think of any other reason for them.
I noticed that at least GraphQLSchema.Builder stores additionalTypes in plain HashSet, while GraphQLSchema itself stores them in LinkedHashSet. Also, GraphQLTypeCollectingVisitor uses plain HashMap, which means GraphQLSchema's typeMap is also a HashMap.

Duplicate issue #1496: Fields returned in introspection query are ordered alphabetically and do not preserve "declaration" order
Created: 2019-04-09T20:24:00Z
When upgrading from GraphQL-Java 11.0 to 12.0 I noticed the fields in the introspection query are suddenly ordered alphabetically.
Before they were ordered in the "natural" (declaration) order they were defined in the schema, which I would prefer.
Especially with tools like GraphiQL and Prisma Playground I would like a certain / "natural"  (declaration) order of my fields. E.g. first start with the id field, and not with e.g. a field alternate_email (because it starts with an a).
Probably related to #1314.

Closing comment (2019-04-10T05:25:19Z): Probably related to #1314.

Not probably related - definitely related
as I said then

I agree with you that a stable introspection system is a win. I have started some PRs to try and address this.


The graphql spec says nothing about a stable order when a type is asked for its fields (althought query results must be stable) and graphql-js itself just uses Object js map behavior which is also not stable.


However in terms of debuggability and predictability a stable order is important. Out SchemaPrinter already does name sorting for stability reasons. I think the graphql types themselves should give out elements in a stable manner

So I get your concerns (eg id first) but they are other competing concerns and stable ordering is the best way we think to be sensible in the face of competing concerns
Preserving "declaration syntax" is a tax on the code we are not willing to have.
We won't be changing this
Repository: graphql/graphql-playground

Issue #683: Auto complete like graphiql
Created: 2018-05-16T00:18:12Z
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground HTML
 GraphQL Playground
 GraphQL Playground Express Middleware
 GraphQL Playground Hapi Middleware
 GraphQL Playground Koa Middleware
 GraphQL Playground Lambda Middleware

What OS and OS version are you experiencing the issue(s) on?
Kubuntu 16.04
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
How do we see the version? Its the latest bundled in Prisma as of 15 May 2018
Its not a bug, only a suggestion:
You MUST have the feature of graphiql:

CTRL+ENTER in front of  { users | } auto-completes with ALL fields of a User (ie it becomes { users {id, name, dob, ...} })
CTRL+ENTER in front of  { users { | }  } auto-completes with required or ID fields of a User (ie it becomes { users { id } })

Life is so much better with these :-)

Duplicate issue #688: Smart auto fill feature for queries
Created: 2018-05-22T16:59:24Z
It would be great to have a smart auto fill feature for queries and mutations, similar to how graphiql does it:

CTRL+ENTER in front of  { users | } auto-completes with ALL fields of a User (ie it becomes { users {id, name, dob, ...} })
CTRL+ENTER in front of  { users { | }  } auto-completes with required or ID fields of a User (ie it becomes { users { id } })

Closing comment (2018-05-24T11:19:43Z): duplicate of #683
Repository: graphql/graphql-playground

Issue #729: [Request] Flatpak image
Created: 2018-06-07T16:46:53Z
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground HTML
 GraphQL Playground
 GraphQL Playground Express Middleware
 GraphQL Playground Hapi Middleware
 GraphQL Playground Koa Middleware
 GraphQL Playground Lambda Middleware

What OS and OS version are you experiencing the issue(s) on?
Linux
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
All
What is the expected behavior?
N/A
What is the actual behavior?
N/A
What steps may we take to reproduce the behavior?
N/A
I'd like to request the electron app to also be packaged and distributed using flatpak and flathub in addition to snapcraft. This will make it easier to reach out and support all different flavors of Linux.

Duplicate issue #1400: Flatpac build
Created: 2022-08-06T04:34:16Z
This issue pertains to the following package(s):

 GraphQL Playground

What OS and OS version are you experiencing the issue(s) on?
I am on fedora.
Please if possible provide a flatpac build of the app. This would be super handy for none snap or deb based linux systems to then have support via flatpac. ie fedora/redhat.

Closing comment (2022-09-29T02:07:38Z): Is this a duplicate of #729 ?
Repository: graphql/graphql-playground

Issue #487: Provide initial context (tabs, queries, headers, variables)
Created: 2018-01-13T18:22:20Z
When using the graphql-playground-react component (or also via e.g. graphql-yoga) it's a common scenario that you'd want to preconfigure a query or provide other context information.

Duplicate issue #301: Replacing GraphiQL
Created: 2017-12-01T19:03:38Z
This issue pertains to:

 GraphQL Playground

After some light investigation, in order to replace GraphiQL with graphql-playground, a few options for pre-filling are necessary. Those are:

 endpointURL: the relative/absolute URL where graphql-playground will make queries to
 query: the GraphQL query to pre-fill
 variables: a JS object of variables to pre-fill
 operationName: the operationName to pre-fill
 result: the result of the query to pre-fill

Closing comment (2018-01-23T16:36:32Z): This is now also tracked in #487.
Repository: graphql/graphql-playground

Issue #225: Package a Windows Store version
Created: 2017-11-11T16:35:01Z
This issue pertains to:

 GraphQL Playground - Electron App
 GraphQL Playground

It's very easy to create a Windows Store build with Electron. You can read the details here: https://electron.atom.io/docs/tutorial/windows-store-guide/. It will make it possible to submit the app to the Windows Store, increasing the reach and making it even easier for ppl to adopt this playground.

Duplicate issue #340: Add AppX Support to Releases
Created: 2017-12-14T16:26:44Z
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground HTML
 GraphQL Playground
 GraphQL Playground Middleware

What OS and OS version are you experiencing the issue(s) on?
Windows 10
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
Any
What is the expected behavior?
Have an AppX package
What is the actual behavior?
No AppX package
Description:
In order to have an AppX installation via Windows Store or as a package, build AppX packages via Desktop App Bridge or a better way if it exists.
The following code should generate an unsigned appx file:
DesktopAppConverter.exe -Installer ./playground-setup-1.3.7.exe -InstallerArguments "/S" -Destination /output/ -PackageName "GraphQLPlayground" -Publisher "CN=GraphCool" -Version 1.1.3.0 -MakeAppx
So it would be nice that the next releases also exists in this format ;)

Closing comment (2017-12-16T07:05:28Z): Similar to (not to say: duplicate of) #225
Repository: graphql/graphql-playground

Issue #965: Schema polling feches new schema, does not update the UI
Created: 2019-02-11T19:15:20Z
Schema polling does not update the UI when new fields are added.
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground

What OS and OS version are you experiencing the issue(s) on?
macOS Mojave 10.14.2
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
1.8.9

What is the expected behavior?
When a field does not exist in the schema, but is present in a query, Playground correctly marks it as an error with a red underline and associated tooltip. When the field is added to the schema and Playground updates in the background, the field should no longer be marked as an error.
What is the actual behavior?
The field is still marked as an error, despite it being present in the IntrospectionQuery result.

(Better quality YouTube version: https://www.youtube.com/watch?v=SbaODtcOh-E)

Duplicate issue #1048: Schema doesn't refresh without hitting refresh in the browser
Created: 2019-06-25T16:37:20Z
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground HTML
 GraphQL Playground
 GraphQL Playground Express Middleware
 GraphQL Playground Hapi Middleware
 GraphQL Playground Koa Middleware
 GraphQL Playground Lambda Middleware

What OS and OS version are you experiencing the issue(s) on?
Windows 10.0.17763 Build 17763
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
Version 1.7.20
What is the expected behavior?
Schema should refresh when I update my code and reboot my server, and the autocomplete should work with new elements added.
What is the actual behavior?
Schema doesnt refresh, autocomplete doesnt work for any new element, but the queries on new element of the schema return the data correctly.
If I use the version 1.7.15 from https://www.graphqlbin.com/v2/6RQ6TM everything works fine
What steps may we take to reproduce the behavior?
Here is my test project :
graphql-basics.zip
1] Comment any query or mutation from the resolver and the schema
2] Run the startDev script
3] Open GraphQL playground in the browser
4] Uncomment what you commented at step 1
5] Try to use it in GraphQL playground, the query/mutation works, but autocomplete doesnt, its highlighted red, and the data in the schema tab on the right isnt updated

Closing comment (2019-06-25T20:55:47Z): Hi @Lumyo, thank you for reporting! It's probably duplicate of #965 so I'm going to close this issue.
Repository: graphql/graphql-playground

Issue #597: Feature Request: FilePicker on Upload scalar
Created: 2018-03-11T17:07:59Z
This issue pertains to the following package(s):

 GraphQL Playground - Electron App
 GraphQL Playground HTML
 GraphQL Playground

Feature Request
Now, where apollo-upload-server seems to be established as the de-facto standard when it comes to handling file uploads, it would be awesome to bring up a file picker dialog on Upload scalars. Something like:

With something like that in place, it wouldn't be necessary to build a client application for testing file uploads anymore.

Duplicate issue #295: File upload support
Created: 2017-12-01T14:29:27Z
File upload is becoming more and more a common feature in GraphQL APIs while debugging file handling is always quite painful. It would be great if the playground supports file upload out of the box, so it's easier to debug when needed.
Would be great to hear about design ideas for this!

Closing comment (2018-11-19T01:38:06Z): Duplicates #597?
Repository: graphql/graphql-playground

Issue #123: FR: Install a protocol handler with Electron app, to be able to open a local playground from the web
Created: 2017-09-27T00:27:45Z
Add a button to the online playground to open locally
Create a protocol handler (for example: graphql://......) and register that with the electron app. This is supported on Windows, Linux and MacOS.

Duplicate issue #90: Open web context in native GraphQL Playground
Created: 2017-09-26T15:25:32Z
For the web-based version of the GraphQL Playground there should be an Open in App button which checks whether the native app is installed. If so the app should open with the same context as on the link otherwise it should download the native app.

Closing comment (2017-09-27T09:18:52Z): Similar to #123
Repository: grpc-ecosystem/grpc-gateway

Issue #832: Update dependencies with security vulnerabilities
Created: 2018-12-17T16:00:32Z
https://github.com/grpc-ecosystem/grpc-gateway/blob/master/docs/Gemfile.lock points to versions with known vulnerabilities:


jekyll: Vulnerable versions: >= 3.7.0, < 3.7.4
Patched version: 3.7.4
Jekyll through 3.6.2, 3.7.x through 3.7.3, and 3.8.x through 3.8.3 allows attackers to access arbitrary files by specifying a symlink in the "include" key in the "_config.yml" file.


rubyzip: CVE-2018-1000544
Vulnerable versions: <= 1.2.1
Patched version: 1.2.2
rubyzip gem rubyzip version 1.2.1 and earlier contains a Directory Traversal vulnerability in Zip::File component that can result in write arbitrary files to the filesystem. This attack appear to be exploitable via If a site allows uploading of .zip files , an attacker can upload a malicious file that contains symlinks or files with absolute pathnames "../" to write arbitrary files to the filesystem..
This is similar to CVE-2017-5946 which was patched in 1.2.1 but the fix in that case was incomplete.


ffi: CVE-2018-1000201 More information
moderate severity
Vulnerable versions: < 1.9.24
Patched version: 1.9.24
ruby-ffi version 1.9.23 and earlier has a DLL loading issue which can be hijacked on Windows OS, when a Symbol is used as DLL name instead of a String This vulnerability appears to have been fixed in v1.9.24 and later.

Duplicate issue #1004: Update integration test dependencies
Created: 2019-08-26T20:51:24Z
Vulnerable dependency reported:
"
Known high severity security vulnerability detected in nokogiri < 1.10.4 defined in Gemfile.lock.
Gemfile.lock update suggested: nokogiri ~> 1.10.4.
"

Closing comment (2019-08-28T10:40:46Z): Dupe of #832
Repository: grpc-ecosystem/grpc-gateway

Issue #3217: Question: How to use grpc_api_configuration when using grpc-agteway remote plugin?
Created: 2023-03-02T11:22:25Z
📚 Documentation
Hi 👋 I want to dockerize the generation of gateway code for my makefile, using the bufbuild/buf docker container and remote plugins. Now I struggle with generating the gateway code and cannot find a good doc on that one, so I added it under "documentation" for now.
My config in buf.gen.yaml is:
...
  - plugin: buf.build/grpc-ecosystem/gateway
    out: gen
    opt:
      - paths=source_relative
      - grpc_api_configuration=gw_mapping.yaml
...

and I've put everything in a flat folder structure to try it out.
Then i cd inside that folder and run docker run --rm -v `pwd`:`pwd` -w `pwd` bufbuild/buf generate .
Result: It generates the *.pb.go and *_grpc.pb.go in a former step also using remote plugins, so I guess that works generally.
But: It always fails with Failure: plugin "buf.build/grpc-ecosystem/gateway:v2.15.2" failed: failed to read gRPC API Configuration description from "gw_mapping.yaml": open gw_mapping.yaml: no such file or directory  and tbh I have no clue if what I try to achieve here is even possible :) The examples at https://github.com/grpc-ecosystem/grpc-gateway#usage-with-remote-plugins don't use it. So would be great to clarify!

Duplicate issue #4394: buf: failed to read gRPC API Configuration description: no such file or directory
Created: 2024-06-02T11:57:57Z
I tried to use buf@v1.32.2 with buf.build/grpc-ecosystem/gateway:v2.20.0 remote plugin. But it gives me this error :
$ buf generate
Failure: plugin "buf.build/grpc-ecosystem/gateway:v2.20.0" failed: failed to read gRPC API Configuration description from "user.yaml": open user.yaml: no such file or directory
Even though when I tried directly using this command, the issue is gone :
$ protoc -I . \                                                                                                                                                                    ─╯
         --grpc-gateway_out . \
         --grpc-gateway_opt paths=source_relative \
         --grpc-gateway_opt grpc_api_configuration=user.yaml \
         user.proto
And this is my buf.gen.yaml :
version: v2
plugins:
  - remote: buf.build/protocolbuffers/go:v1.33.0
    out: .
    opt: paths=source_relative
  - remote: buf.build/grpc/go:v1.3.0
    out: .
    opt:
      - require_unimplemented_servers=false
      - paths=source_relative  
  - remote: buf.build/grpc-ecosystem/gateway:v2.20.0
    out: .
    opt:
      - paths=source_relative
      - grpc_api_configuration=user.yaml
  - remote: buf.build/grpc-ecosystem/openapiv2:v2.16.2
    out: .
Am I missing something?

Closing comment (2024-06-02T12:18:38Z): duplicate #3217
Repository: grpc-ecosystem/grpc-gateway

Issue #755: Support go modules
Created: 2018-09-12T22:04:23Z
Steps you follow to reproduce the error:

Using go1.11 outside of go path
Run go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway

Returns
go: finding github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway latest

# github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway/descriptor

../../go/pkg/mod/github.com/grpc-ecosystem/grpc-gateway@v1.5.0/protoc-gen-grpc-gateway/descriptor/services.go:146:49: opts.ResponseBody undefined (type *annotations.HttpRule has no field or method ResponseBody)
-->

What did you expect to happen instead:
Successfully added to mod file
It seems like it's able to find the latest version 1.5.0, but then isn't up to date? The error that's output seems to be what was fixed with #731

Duplicate issue #829: Using dep to depend on specific revision of golang/protobuf is causing transative dependency problems for users
Created: 2018-12-12T08:03:04Z
grpc-gateway/Gopkg.toml
    
    
         Line 41
      in
      a7c0cd0
    
  
  
    

        
          
           revision = "aa810b61a9c79d51363740d207bb46cf8e620ed5" 
        
    
  


master: Could not introduce github.com/grpc-ecosystem/grpc-gateway@master, as it has a dependency on github.com/golang/protobuf with constraint aa810b61a9c79d51363740d207bb46cf8e620ed5, which has no overlap with existing constraint master from github.com/grpc-ecosystem/go-grpc-middleware@master

Closing comment (2019-02-18T20:39:16Z): Closing as dupe of #755
Repository: grpc-ecosystem/grpc-gateway

Issue #201: Fields bound by path template also in body (Swagger)
Created: 2016-07-25T15:48:10Z
https://github.com/googleapis/googleapis/blob/master/google/api/http.proto#L123



HTTP
RPC




PUT /v1/messages/123456 { "text": "Hi!" }
UpdateMessage(message_id: "123456" message { text: "Hi!" })



The special name * can be used in the body mapping to define that
every field not bound by the path template should be mapped to the
request body.  This enables the following alternative definition of
the update method:
service Messaging {
  rpc UpdateMessage(Message) returns (Message) {
    option (google.api.http) = {
      put: "/v1/messages/{message_id}"
      body: "*"
    };
  }
}
message Message {
  string message_id = 1;
  string text = 2;
}

Currently, this doesn't seem to work when generating the Swagger definition, as both fields are showing up. This is a snippet from my .proto file.
service Application {
    rpc Update(UpdateApplicationRequest) returns (UpdateApplicationResponse) {
        option (google.api.http) = {
            put: "/api/v1/application/{appEUI}"
            body: "*"
        };
    }
}

message UpdateApplicationRequest {
    string appEUI = 1;
    string name = 2;
}


I would have expected to ony have name in the request body. Leaving out the devEUI does work however when making requests!
When setting body: "name" in the .proto file (see also http.proto#L109), the API returns the following error (even if the appEUI is included in the body too):
{
  "Error": "json: cannot unmarshal object into Go value of type string",
  "Code": 3
}

Duplicate issue #1157: Path parameters visible in the body of the request
Created: 2020-03-05T11:20:17Z
Request
Method: POST

The input has been defined as a path parameter. Yet, its visible as a part of the request.

Closing comment (2020-03-05T11:25:20Z): Duplicate of #201
Repository: grpc-ecosystem/grpc-gateway

Issue #303: Generating swagger version, contact name etc in generated docs
Created: 2017-01-19T21:51:41Z
Is there a way to pass high level swagger fields via proto (e.g. info details such as license:name, contact:name etc).
Also, I see that the generated swagger docs has :  "version": "version not set".  How can I pass version via proto?

Duplicate issue #437: swagger title and version hardcoded
Created: 2017-07-18T01:28:52Z
Currently the swagger files generated by protoc-gen-swagger have title and version attributes which aren't very useful -
e.g.
"info": {
    "title": "proto/file.proto",
    "version": "version not set"
  },
It would be great if these values better matched the spec, including a title for the service and some version information.

Closing comment (2017-08-01T05:31:04Z): Related to #303
Repository: grpc-ecosystem/grpc-gateway

Issue #702: The swagger plugin couldn’t distinguish two rpcs if we use the resource name design style.
Created: 2018-07-15T12:50:51Z
The swagger plugin couldn’t distinguish two rpcs designed according to the Google API Design Guide Resource Names as below:
  rpc GetService(GetServiceRequest) returns (Service) {
    option (google.api.http) = {
      get: "/v1/{name=service_categories/*/services/*}"
    };
    option (grpc.gateway.protoc_gen_swagger.options.openapiv2_operation) = {
      description: "Get a service.The **name** must have the format of `service_categories/*/services/*`.";
      tags: "Service";
    };
  }

  rpc GetUser(GetUserRequest) returns (User) {
    option (google.api.http) = {
      get: "/v1/{name=users/*}"
    };
    option (grpc.gateway.protoc_gen_swagger.options.openapiv2_operation) = {
      description: "Get a user.The **name** must have the format of `users/*`.";
      tags: "User";
    };
  }

The two generated results from the swagger plugin both use the /v1/{name} as the key.
There is no problem if we use ID as the user input, but according to the Google API Design Guide the name is a better choice.
Is there any solution about this issue?

Duplicate issue #2976: swagger execute with wrong url when using post: "/v1/Things/{thing}/Services/{service}"
Created: 2022-10-24T09:52:59Z
🐛 Bug Report
When using post: "/v1/Things/{thing}/Services/{service}", swagger execute with wrong url.
Expected behavior
Should call http://localhost:8080/v1/Things/Thing1/Services/Start
Actual Behavior

Closing comment (2022-10-24T10:35:24Z): It is related to #702 and #2562
so how to use string name = 1 [(grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {field_configuration: {path_param_name: "shelfName"}}];
I am using buf
unknown extension grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field
this is my buf.gen.yaml
version: v1
plugins:
  - name: go
    out: api/gen/proto/go
    opt:
      - paths=source_relative
  - name: go-grpc
    out: api/gen/proto/go
    opt:
      - paths=source_relative
  - name: grpc-gateway
    out: api/gen/proto/go
    opt:
      - paths=source_relative
  - name: openapiv2
    out: docs/swagger
    opt:
      - allow_merge=true
    strategy: all

buf.yaml
version: v1
deps:
  - buf.build/googleapis/googleapis
  - buf.build/grpc-ecosystem/grpc-gateway
breaking:
  use:
    - FILE
lint:
  use:
    - DEFAULT