web-ext icon indicating copy to clipboard operation
web-ext copied to clipboard

Cannot use web-ext sign: Error: Got a 404 response when downloading...

Open nitroetnies opened this issue 8 years ago • 6 comments

Is this a bug or feature request?

bug

What is the current behavior?

using web-ext sign --api-key <my-user:1234.123> --api-secret <my-secret-12sfjwerz123j4h>

gives

Using previously auto-generated extension ID: {some-id-comes-here}
Validating add-on [..........................................................................................................................................]
Validation results: https://addons.mozilla.org/en-US/developers/upload/asdfjasdkfjdksafj
Downloading signed files: ...
/usr/local/lib/node_modules/web-ext/node_modules/sign-addon/dist/webpack:/src/amo-client.js:283
              throw new Error(
                    ^
Error: Got a 404 response when downloading https://addons.mozilla.org/api/v3/file/12314/my-extension-1.2-an+fx.xpi?src=api
    at Request.<anonymous> (/usr/local/lib/node_modules/web-ext/node_modules/sign-addon/dist/webpack:/src/amo-client.js:283:21)
    at emitOne (events.js:77:13)
    at Request.emit (events.js:169:7)
    at Request.onRequestResponse (/usr/local/lib/node_modules/web-ext/node_modules/sign-addon/node_modules/request/request.js:954:10)
    at emitOne (events.js:77:13)
    at ClientRequest.emit (events.js:169:7)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:430:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:103:23)
    at TLSSocket.socketOnData (_http_client.js:320:20)
    at emitOne (events.js:77:13)

Furthermore, the .xpi cannot be downloaded using curl (with jwt token).

What is the expected or desired behavior?

make this work

Version information

(Please fill this in for bug reports.)

  • Output of web-ext --version: 1.6.0
  • Output of node --version: v4.4.5
  • Output of npm --version: 2.15.5
  • Firefox version: 50.1.0
  • Your OS and version: Mac OS El Capitan Version 10.11.6

nitroetnies avatar Dec 16 '16 15:12 nitroetnies

Huh, does it happen repeatedly? Just wondering if it's caching related. That URL is a 401 for me, not a 404, which suggests that it's accessible now. If it's possible, could you upload a log using --verbose? It will redact all sensitive info.

kumar303 avatar Dec 16 '16 18:12 kumar303

Is this still happening? If I could see a verbose log it would be helpful

kumar303 avatar Jan 05 '17 21:01 kumar303

I keep getting the same error, and my --verbose output is here. Whenever I try going to the 404 url I get an error saying the authentication credentials are not correct (that error message is here, in the same gist).

TexAgg avatar May 12 '17 03:05 TexAgg

Thanks for the log. I think this is an eventual consistency issue. We use Amazon S3 to store files so what may be happening is that the file is not yet available. To fix it, we would need to retry the 404 URL in a loop a couple times until it becomes available.

kumar303 avatar May 12 '17 17:05 kumar303

Could you try reproducing this? If you were experiencing https://github.com/mozilla/web-ext/issues/1111 then we pushed a fix to the signing API which should address it. However, if your bug is entirely related to eventual consistency then it won't be fixed.

kumar303 avatar Sep 27 '18 18:09 kumar303

I ran into this today. Not only do I get a 404 error in the output of the web-ext tool, the link in the email I get saying the extension is ready also throws a 404 error.

DmitriK avatar Nov 20 '18 19:11 DmitriK