Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
// @flow
|
|
|
|
import * as tus from 'tus-js-client';
|
2022-02-22 16:11:22 +01:00
|
|
|
import NoopUrlStorage from 'tus-js-client/lib/noopUrlStorage';
|
2021-11-12 09:30:33 +01:00
|
|
|
import analytics from '../../ui/analytics';
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
import { X_LBRY_AUTH_TOKEN } from '../../ui/constants/token';
|
|
|
|
import { doUpdateUploadAdd, doUpdateUploadProgress, doUpdateUploadRemove } from '../../ui/redux/actions/publish';
|
|
|
|
import { LBRY_WEB_PUBLISH_API_V2 } from 'config';
|
|
|
|
|
|
|
|
const RESUMABLE_ENDPOINT = LBRY_WEB_PUBLISH_API_V2;
|
|
|
|
const RESUMABLE_ENDPOINT_METHOD = 'publish';
|
2022-06-29 14:34:25 +02:00
|
|
|
const UPLOAD_CHUNK_SIZE_BYTE = 25 * 1024 * 1024;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
2021-11-12 07:12:51 +01:00
|
|
|
const STATUS_CONFLICT = 409;
|
|
|
|
const STATUS_LOCKED = 423;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether a given status is in the range of the expected category.
|
|
|
|
*
|
|
|
|
* @param status
|
|
|
|
* @param category
|
|
|
|
* @returns {boolean}
|
|
|
|
*/
|
|
|
|
function inStatusCategory(status, category) {
|
|
|
|
return status >= category && status < category + 100;
|
|
|
|
}
|
|
|
|
|
2022-02-27 10:19:08 +01:00
|
|
|
function getTusErrorType(errMsg: string) {
|
|
|
|
if (errMsg.startsWith('tus: failed to upload chunk at offset')) {
|
|
|
|
// This is the only message that contains dynamic value prior to the first comma.
|
|
|
|
return 'tus: failed to upload chunk at offset';
|
|
|
|
} else {
|
|
|
|
return errMsg.startsWith('tus:') ? errMsg.substring(0, errMsg.indexOf(',')) : errMsg;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
export function makeResumableUploadRequest(
|
|
|
|
token: string,
|
|
|
|
params: FileUploadSdkParams,
|
|
|
|
file: File | string,
|
|
|
|
isPreview?: boolean
|
|
|
|
) {
|
|
|
|
return new Promise<any>((resolve, reject) => {
|
|
|
|
if (!RESUMABLE_ENDPOINT) {
|
|
|
|
reject(new Error('Publish: endpoint undefined'));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (params.remote_url) {
|
|
|
|
reject(new Error('Publish: v2 does not support remote_url'));
|
|
|
|
}
|
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
const { uploadUrl, guid, ...sdkParams } = params;
|
2021-11-12 06:59:51 +01:00
|
|
|
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
const jsonPayload = JSON.stringify({
|
|
|
|
jsonrpc: '2.0',
|
|
|
|
method: RESUMABLE_ENDPOINT_METHOD,
|
2021-12-07 15:48:09 +01:00
|
|
|
params: sdkParams,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
id: new Date().getTime(),
|
|
|
|
});
|
|
|
|
|
2021-11-22 08:33:32 +01:00
|
|
|
const urlOptions = {};
|
|
|
|
if (params.uploadUrl) {
|
|
|
|
// Resuming from previous upload. TUS clears the resume fingerprint on any
|
|
|
|
// 4xx error, so we need to use the fixed URL mode instead.
|
|
|
|
urlOptions.uploadUrl = params.uploadUrl;
|
|
|
|
} else {
|
|
|
|
// New upload, so use `endpoint`.
|
|
|
|
urlOptions.endpoint = RESUMABLE_ENDPOINT;
|
|
|
|
}
|
|
|
|
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
const uploader = new tus.Upload(file, {
|
2021-11-22 08:33:32 +01:00
|
|
|
...urlOptions,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
chunkSize: UPLOAD_CHUNK_SIZE_BYTE,
|
2022-06-28 12:29:07 +02:00
|
|
|
retryDelays: [8000, 10000, 15000, 20000, 30000],
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
parallelUploads: 1,
|
2021-12-13 08:35:21 +01:00
|
|
|
storeFingerprintForResuming: false,
|
2022-02-22 16:11:22 +01:00
|
|
|
urlStorage: new NoopUrlStorage(),
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
removeFingerprintOnSuccess: true,
|
|
|
|
headers: { [X_LBRY_AUTH_TOKEN]: token },
|
|
|
|
metadata: {
|
|
|
|
filename: file instanceof File ? file.name : file,
|
|
|
|
filetype: file instanceof File ? file.type : undefined,
|
|
|
|
},
|
|
|
|
onShouldRetry: (err, retryAttempt, options) => {
|
2021-12-07 15:48:09 +01:00
|
|
|
window.store.dispatch(doUpdateUploadProgress({ guid, status: 'retry' }));
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
const status = err.originalResponse ? err.originalResponse.getStatus() : 0;
|
2022-01-10 09:28:25 +01:00
|
|
|
return !inStatusCategory(status, 400) || status === STATUS_CONFLICT || status === STATUS_LOCKED;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
},
|
2021-11-22 09:06:28 +01:00
|
|
|
onError: (err) => {
|
|
|
|
const status = err.originalResponse ? err.originalResponse.getStatus() : 0;
|
2021-11-23 04:23:05 +01:00
|
|
|
const errMsg = typeof err === 'string' ? err : err.message;
|
|
|
|
|
2022-01-13 02:43:21 +01:00
|
|
|
let customErr;
|
|
|
|
if (status === STATUS_LOCKED || errMsg === 'file currently locked') {
|
|
|
|
customErr = 'File is locked. Try resuming after waiting a few minutes';
|
2021-11-22 09:06:28 +01:00
|
|
|
}
|
2022-01-13 02:43:21 +01:00
|
|
|
|
|
|
|
window.store.dispatch(doUpdateUploadProgress({ guid, status: 'error' }));
|
2022-02-27 10:19:08 +01:00
|
|
|
analytics.sentryError(getTusErrorType(errMsg), { onError: err, tusUpload: uploader });
|
2022-01-24 05:25:54 +01:00
|
|
|
|
2022-01-13 02:43:21 +01:00
|
|
|
reject(
|
|
|
|
// $FlowFixMe - flow's constructor for Error is incorrect.
|
|
|
|
new Error(customErr || err, {
|
|
|
|
cause: {
|
2022-03-18 10:04:57 +01:00
|
|
|
// ...(uploader._fingerprint ? { fingerprint: uploader._fingerprint } : {}),
|
|
|
|
// ...(uploader._retryAttempt ? { retryAttempt: uploader._retryAttempt } : {}),
|
|
|
|
// ...(uploader._offsetBeforeRetry ? { offsetBeforeRetry: uploader._offsetBeforeRetry } : {}),
|
2022-01-13 02:43:21 +01:00
|
|
|
...(customErr ? { original: errMsg } : {}),
|
|
|
|
},
|
|
|
|
})
|
|
|
|
);
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
},
|
|
|
|
onProgress: (bytesUploaded, bytesTotal) => {
|
|
|
|
const percentage = ((bytesUploaded / bytesTotal) * 100).toFixed(2);
|
2021-12-07 15:48:09 +01:00
|
|
|
window.store.dispatch(doUpdateUploadProgress({ guid, progress: percentage }));
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
},
|
|
|
|
onSuccess: () => {
|
2021-11-12 04:09:25 +01:00
|
|
|
let retries = 1;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
2021-11-11 02:55:48 +01:00
|
|
|
function makeNotifyRequest() {
|
|
|
|
const xhr = new XMLHttpRequest();
|
|
|
|
xhr.open('POST', `${uploader.url}/notify`);
|
|
|
|
xhr.setRequestHeader('Content-Type', 'application/json');
|
|
|
|
xhr.setRequestHeader('Tus-Resumable', '1.0.0');
|
|
|
|
xhr.setRequestHeader(X_LBRY_AUTH_TOKEN, token);
|
|
|
|
xhr.responseType = 'json';
|
2022-07-01 01:30:08 +02:00
|
|
|
xhr.onloadstart = () => {
|
|
|
|
window.store.dispatch(doUpdateUploadProgress({ guid, status: 'notify' }));
|
|
|
|
};
|
2021-11-11 02:55:48 +01:00
|
|
|
xhr.onload = () => {
|
2021-12-07 15:48:09 +01:00
|
|
|
window.store.dispatch(doUpdateUploadRemove(guid));
|
2021-11-11 02:55:48 +01:00
|
|
|
resolve(xhr);
|
|
|
|
};
|
|
|
|
xhr.onerror = () => {
|
2021-11-12 04:09:25 +01:00
|
|
|
if (retries > 0 && xhr.status === 0) {
|
|
|
|
--retries;
|
2021-11-12 09:30:33 +01:00
|
|
|
analytics.error('notify: first attempt failed (status=0). Retrying after 10s...');
|
2021-11-12 04:09:25 +01:00
|
|
|
setTimeout(() => makeNotifyRequest(), 10000); // Auto-retry after 10s delay.
|
2021-11-11 02:55:48 +01:00
|
|
|
} else {
|
2021-12-07 15:48:09 +01:00
|
|
|
window.store.dispatch(doUpdateUploadProgress({ guid, status: 'error' }));
|
2021-11-12 01:59:07 +01:00
|
|
|
reject(new Error(`There was a problem in the processing. Please retry. (${xhr.status})`));
|
2021-11-11 02:55:48 +01:00
|
|
|
}
|
|
|
|
};
|
|
|
|
xhr.onabort = () => {
|
2021-12-07 15:48:09 +01:00
|
|
|
window.store.dispatch(doUpdateUploadRemove(guid));
|
2021-11-11 02:55:48 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
xhr.send(jsonPayload);
|
|
|
|
}
|
|
|
|
|
2021-11-12 11:34:08 +01:00
|
|
|
setTimeout(() => makeNotifyRequest(), 15000);
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
},
|
|
|
|
});
|
|
|
|
|
2022-02-22 16:11:22 +01:00
|
|
|
window.store.dispatch(doUpdateUploadAdd(file, params, uploader));
|
|
|
|
uploader.start();
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
});
|
|
|
|
}
|