gidgethub.InvalidField: Validation Failed for 'q'

[mpushki]

Try to use /search/issues. my query works good on guthub page. But I get problem in getitem

await gh.getitem(f"/search/issues?q=type:pr")
await gh.getitem(f"/search/issues?q=is::pr")

Get error - gidgethub.InvalidField: Validation Failed for 'q'
But
await gh.getitem(f"/search/issues?q=is:merged+type:pr") works
Also my repo contains dots. And
await gh.getitem(f"/search/issues?q=repo:{name_with_dots}") does not work.
My last params is date: merged:>YYYY-MM-DD - it does not work too in gh.getitem

It looks so strange. Could you please help me with this problem?

[brettcannon]

You probably need to quote the URLs. See https://docs.python.org/3/library/urllib.parse.html#urllib.parse.quote for one possible solution.

Also notice that your second example has double colons, ::, which is not valid.

[manterfield]

The issue is likely permissions. I'm getting the same behaviour on this endpoint if I add repo, org or user query fields.

I tried the same call via curl and got the following response:

{
  "message": "Validation Failed",
  "errors": [
    {
      "message": "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.",
      "resource": "Search",
      "field": "q",
      "code": "invalid"
    }
  ],
  "documentation_url": "https://docs.github.com/v3/search/"
}

Two thoughts on this:

• I should have the proper perms, so perhaps this is a bug with GitHub (or at least surprising behaviour).
• Gidgethub is suppressing really useful info here. I've searched and not found a setting that allows me to configure the detail of the errors I get back or otherwise inspect them properly. If there is a way to get this info I'd love to be pointed in that direction. The message that comes back in an error payload is pretty critical.

Turns out I can just catch the exception and the detail is in the .errors attribute of the exception. Would still be a time saver to see that info in the main exception message, but I don't know how large that can potentially become.

If I figure out the proper perms I'll report back.

---

Reporting back:

This error is returned if your search query limits you to a set of private repositories (and no public ones). i.e. if you searched an org that had only private repos and no public ones, you get this permission error.

The search docs say that you need metadata perms to access this info, but that's incorrect. According to GitHub support you actually need content:read on the org/user/private repo you are searching against.

[Mariatta]

I encountered the same error, when using the GH Search API for a user that doesn't exist.

This query works ok:

# searching for GvR's involvements in the Python org
await gh.getitem("/search/issues?q=involves:gvanrossum+org:python") # returns 200 OK

This query returns 422:

# username Qa11223344 doesn't exist
await gh.getitem("/search/issues?q=involves:Qa11223344+org:python") # returns 422 Validation Failed

I received the same error as @manterfield has shared above:

{
  "message": "Validation Failed",
  "errors": [
    {
      "message": "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.",
      "resource": "Search",
      "field": "q",
      "code": "invalid"
    }
  ],
  "documentation_url": "https://docs.github.com/v3/search/"
}

It seems like the Validation Failed message doesn't describe the underlying issue, that the user is not found.
The part that handles this error message is here:

https://github.com/brettcannon/gidgethub/blob/9096d1b79447a3ef81b331457ea39c43f43e2f2d/gidgethub/sansio.py#L355

So in this case it simply says that field q is invalid instead of using the value of errors[0]["message"].

I wonder if we should change the behavior here to use the errors[0]["message"] first if exists, since it's more useful.

[brettcannon]

I wonder if we should change the behavior here to use the errors[0]["message"] first if exists, since it's more useful.

Any idea on how that would look with multiple errors?