Let's imagine that we have a ~4gb file, and a premium subscription on the account. So we are trying to upload the file using preliminary wrappers, we do perform the request, wait until the file is loaded, and chunk are saved on the server-side/cdn whatever, close the database, then we open it again, let's say 10 minutes later, we are trying to upload it, but due to the tdlib cache we just run into a weird situation where the filds 'is_uploading_active' are being set as true in the response to the original 'preliminaryUploadFile', even though the file is already uploaded and the uploaded_size matches the size, and expected_size fields values, while 'is_uploading_completed' is being set to false. #579
Let's imagine that we have a ~4gb file, and a premium subscription on the account. So we are trying to upload the file using preliminary wrappers, we do perform the request, wait until the file is loaded, and chunk are saved on the server-side/cdn whatever, close the database, then we open it again, let's say 10 minutes later, we are trying to upload it, but due to the tdlib cache we just run into a weird situation where the filds 'is_uploading_active' are being set as true in the response to the original 'preliminaryUploadFile', even though the file is already uploaded and the uploaded_size matches the size, and expected_size fields values, while 'is_uploading_completed' is being set to false.
Then, we do receive 3 updateFiles, last 2 of which are identical, so even if i am going to use a deferred promise its still remaining unreliable? And both are set with is_uploading_active, is_uploading_completed - false, so how do we exactly determine when we should deal with the file now?
So there's no other updates besides these ones, no matter how long you wait for.
Should we simply rely on expected_size === uploaded_size condition instead?
And please, do not reply as 'Updates [updateFile]() will be used to notify about upload progress and successful completion of the upload. The file will not have a persistent remote identifier until it is sent in a message.', it can't be applied in current context since we simply do not even know when the file is uploaded to send the message, even though some clients ignore it completely and send files as is even before they were uploaded. Such as inline music bots etc. Shall we replicate their behaviour? Yet i need to know what to rely on after restarts.
Then, we do receive 3 updateFiles, last 2 of which are identical, so even if i am going to use a deferred promise its still remaining unreliable? And both are set with is_uploading_active, is_uploading_completed - false, so how do we exactly determine when we should deal with the file now?
preliminaryUploadFile
As you can see its still stating 'is_uploading_active' as true and the other field as false etc. ```bash res { _: 'file', id: 1229, size: 4151822324, expected_size: 4151822324, local: { _: 'localFile', path: '/media/root/732d2c75-7703-405f-ab61-22daf460bdf51/root/Videos/2023-12-17_08.22.44.mp4', can_be_downloaded: false, can_be_deleted: false, is_downloading_active: false, is_downloading_completed: true, download_offset: 0, downloaded_prefix_size: 4151822324, downloaded_size: 4151822324 }, remote: { _: 'remoteFile', id: '', unique_id: '', is_uploading_active: true, is_uploading_completed: false, uploaded_size: 4151822324 } } ```updateFile # 1
'is_uploading_active: true, is_uploading_completed: false,' ```bash { _: 'updateFile', file: { _: 'file', id: 1229, size: 4151822324, expected_size: 4151822324, local: { _: 'localFile', path: '/media/root/732d2c75-7703-405f-ab61-22daf460bdf51/root/Videos/2023-12-17_08.22.44.mp4', can_be_downloaded: false, can_be_deleted: false, is_downloading_active: false, is_downloading_completed: true, download_offset: 0, downloaded_prefix_size: 4151822324, downloaded_size: 4151822324 }, remote: { _: 'remoteFile', id: '', unique_id: '', is_uploading_active: true, is_uploading_completed: false, uploaded_size: 4151822324 } } } ```updateFile # 2
'is_uploading_active: false, is_uploading_completed: false,' ```bash { _: 'updateFile', file: { _: 'file', id: 1228, size: 4151822324, expected_size: 4151822324, local: { _: 'localFile', path: '/media/root/732d2c75-7703-405f-ab61-22daf460bdf51/root/Videos/2023-12-17_08.22.44.mp4', can_be_downloaded: false, can_be_deleted: false, is_downloading_active: false, is_downloading_completed: true, download_offset: 0, downloaded_prefix_size: 4151822324, downloaded_size: 4151822324 }, remote: { _: 'remoteFile', id: '', unique_id: '', is_uploading_active: false, is_uploading_completed: false, uploaded_size: 4151822324 } } } ```updateFile # 3
'is_uploading_active: false, is_uploading_completed: false,' ```bash { _: 'updateFile', file: { _: 'file', id: 1229, size: 4151822324, expected_size: 4151822324, local: { _: 'localFile', path: '/media/root/732d2c75-7703-405f-ab61-22daf460bdf51/root/Videos/2023-12-17_08.22.44.mp4', can_be_downloaded: false, can_be_deleted: false, is_downloading_active: false, is_downloading_completed: true, download_offset: 0, downloaded_prefix_size: 4151822324, downloaded_size: 4151822324 }, remote: { _: 'remoteFile', id: '', unique_id: '', is_uploading_active: false, is_uploading_completed: false, uploaded_size: 4151822324 } } } ```So there's no other updates besides these ones, no matter how long you wait for.
Should we simply rely on expected_size === uploaded_size condition instead? And please, do not reply as 'Updates [updateFile]() will be used to notify about upload progress and successful completion of the upload. The file will not have a persistent remote identifier until it is sent in a message.', it can't be applied in current context since we simply do not even know when the file is uploaded to send the message, even though some clients ignore it completely and send files as is even before they were uploaded. Such as inline music bots etc. Shall we replicate their behaviour? Yet i need to know what to rely on after restarts.
Originally posted by @iiscosd3 in https://github.com/tdlib/td/issues/2860#issuecomment-2076423972