{"action":"created","issue":{"url":"https://api.github.com/repos/itchio/butler/issues/71","repository_url":"https://api.github.com/repos/itchio/butler","labels_url":"https://api.github.com/repos/itchio/butler/issues/71/labels{/name}","comments_url":"https://api.github.com/repos/itchio/butler/issues/71/comments","events_url":"https://api.github.com/repos/itchio/butler/issues/71/events","html_url":"https://github.com/itchio/butler/issues/71","id":171767211,"number":71,"title":"Fix wharf's resumable upload client behavior + collect error traces in case of service degradation","user":{"login":"quyse","id":416215,"avatar_url":"https://avatars.githubusercontent.com/u/416215?v=3","gravatar_id":"","url":"https://api.github.com/users/quyse","html_url":"https://github.com/quyse","followers_url":"https://api.github.com/users/quyse/followers","following_url":"https://api.github.com/users/quyse/following{/other_user}","gists_url":"https://api.github.com/users/quyse/gists{/gist_id}","starred_url":"https://api.github.com/users/quyse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/quyse/subscriptions","organizations_url":"https://api.github.com/users/quyse/orgs","repos_url":"https://api.github.com/users/quyse/repos","events_url":"https://api.github.com/users/quyse/events{/privacy}","received_events_url":"https://api.github.com/users/quyse/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/itchio/butler/labels/infrastructure","name":"infrastructure","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":63,"created_at":"2016-08-17T21:40:22Z","updated_at":"2016-08-29T09:49:32Z","closed_at":null,"body":"I'm getting the following error while trying to push new version of a file.\r\n```\r\n$ butler push linux quyse/flaw:model-editor-linux\r\n> For channel `model-editor-linux`: last build is 3183, downloading its signature\r\n\r\n> Pushing 8.0 MB (1 files, 0 dirs, 0 symlinks)\r\n*errors.errorString itch.io API error: uploaded file does not exist in storage (build/4513/13440-signature-default: 404)\r\n/usr/local/go/src/runtime/asm_amd64.s:1998 (0x490431)\r\n```\r\nWhat does it possibly mean? I've recently upgraded docker container which is pushing builds during CI, but I don't think I've changed anything about butler."},"comment":{"url":"https://api.github.com/repos/itchio/butler/issues/comments/243081797","html_url":"https://github.com/itchio/butler/issues/71#issuecomment-243081797","issue_url":"https://api.github.com/repos/itchio/butler/issues/71","id":243081797,"user":{"login":"fasterthanlime","id":7998310,"avatar_url":"https://avatars.githubusercontent.com/u/7998310?v=3","gravatar_id":"","url":"https://api.github.com/users/fasterthanlime","html_url":"https://github.com/fasterthanlime","followers_url":"https://api.github.com/users/fasterthanlime/followers","following_url":"https://api.github.com/users/fasterthanlime/following{/other_user}","gists_url":"https://api.github.com/users/fasterthanlime/gists{/gist_id}","starred_url":"https://api.github.com/users/fasterthanlime/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fasterthanlime/subscriptions","organizations_url":"https://api.github.com/users/fasterthanlime/orgs","repos_url":"https://api.github.com/users/fasterthanlime/repos","events_url":"https://api.github.com/users/fasterthanlime/events{/privacy}","received_events_url":"https://api.github.com/users/fasterthanlime/received_events","type":"User","site_admin":false},"created_at":"2016-08-29T09:49:32Z","updated_at":"2016-08-29T09:49:32Z","body":"I'm currently cleaning up `uploader/resumable.go` to account for the information in this thread (thanks a ton for the details).\r\n\r\nI'm still thinking about this though:\r\n\r\n> One of the requests seen by the engineer who was doing the performance analysis was a request that had both Content-Length: 0 and Content-Range: bytes 33554432-50331647/*; this seems to indicate the client thinks it is sending a chunk, but it is sending zero bytes. The service behavior in this case is not defined; the current behavior is if you had sent Content-Range: bytes */* and it was a query-status request. Although I do not have a reference, apparently the next request in sequence was for the next chunk, and because the bytes of the current chunk were never sent, a mismatched_content_start error was returned, presumably repeatedly.\r\n\r\nCould it be a reverse proxy problem? Because the logic behind computing the `Content-Range` is deceptively simple right now and directly tied to the buffer's size - I just can't see where it would go wrong. However, a reverse proxy dropping the content because of a connection problem between the client and the proxy at some point, might explain why the header went through but the content didn't.\r\n\r\nMy other theory is that the buffer got modified between the Content-Range computation and the request actually starting to upload. I'll add a check for that."}}
{"actor":{"display_login":"fasterthanlime"}}