Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metadata error isn't helpful #491

Open
jyasskin opened this issue Sep 25, 2017 · 5 comments
Open

Metadata error isn't helpful #491

jyasskin opened this issue Sep 25, 2017 · 5 comments

Comments

@jyasskin
Copy link
Member

https://lists.w3.org/Archives/Public/public-tr-notifications/2017Sep/0104.html says:

On Mon Sep 25 20:45:02 UTC 2017, the request to publish https://raw.githubusercontent.com/w3c/permissions/master/.echidna failed. See details below.
...
  "results": {
    "status": "error",
    "jobs": {
      "retrieve-resources": {
        "status": "ok",
        "errors": []
      },
      "metadata": {
        "status": "error",
        "errors": [
          "Error: Not Found"
        ]
      },
...
      {
        "time": "2017-09-25T20:45:02.554Z",
        "fact": "An error occurred while running the metadata extractor."
      }

This doesn't help me figure out how to fix the metadata.

@tripu
Copy link
Member

tripu commented Oct 16, 2017

@jyasskin, the URL that is passed to Echidna should be either the spec to publish, or a manifest. The way Echidna discerns which one it is is by checking whether the first char is < (spec) or not (manifest).

I think in this case you should pass the actual URL of the spec (https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/w3c/permissions/master/index.bs&md-status=WD&md-prepare-for-tr=true), not the URL of a file containing the URL of the spec (https://raw.githubusercontent.com/w3c/permissions/master/.echidna).

@tripu tripu closed this as completed Oct 16, 2017
@jyasskin
Copy link
Member Author

Please say that in the error message.

@tripu
Copy link
Member

tripu commented Oct 30, 2017

“Please say that in the error message.”

@jyasskin, I'm not sure that checking for this specific type of mistake makes sense in Echidna. The URL posted to Echidna must be either the spec itself, or a manifests (ie, a list of relative links).

The URL submitted could be anything else by mistake (a Git repository, an image). I'm not sure Echidna should check for all possible errors, and report specifically about those.

An analogy to illustrate my point: when I submit to Bikeshed a URL that is not a Bikeshed source file (as it should be), I don't get an error saying so. I just get a generic error (in this case, not even so; just a blank page).

@jyasskin
Copy link
Member Author

The file here was detected as a manifest (since https://raw.githubusercontent.com/w3c/permissions/master/.echidna doesn't start with a <) but then didn't parse as a manifest (since the URL was absolute). That failure to parse seems like the right thing to report.

https://raw.githubusercontent.com/w3c/permissions/master/.echidna is not a valid manifest (https://github.com/w3c/echidna/wiki/Preparing-your-document#manifest-file)

might be a good error. Talking about a "metadata extractor" makes it seem like I should be looking at https://github.com/w3c/echidna/wiki/Metadata-extracted-from-the-document, which implies that you've already found a spec document using my manifest, which wasn't true.

@tripu
Copy link
Member

tripu commented Oct 30, 2017

Okay, @jyasskin.
I'll try to work on better errors for this specific issue (a manifest containing an absolute URI).

@tripu tripu reopened this Oct 30, 2017
@tripu tripu self-assigned this Oct 30, 2017
@tripu tripu removed their assignment Sep 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants