ref: Extract general chunk uploading logic from `upload_difs_chunked` by szokeasaurusrex · Pull Request #2303 · getsentry/sentry-cli

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex · 2024-12-05T13:22:21Z

The upload_difs_chunked function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

loewenheim · 2024-12-05T15:58:28Z

+fn render_detail(detail: &Option<String>, fallback: Option<&str>) {
+ let mut string = match *detail {
+ Some(ref string) => string.as_str(),
+ None => "",
+ };
+
+ if string.is_empty() {
+ if let Some(fallback) = fallback {
+ string = fallback;
+ }
+ }


&Option<…> in a function signature is kind of a code smell; you can always do better by taking Option<&…> instead. You just have to call it with .as_ref(), or in this case .as_deref().
The logic of picking the detail or the fallback can be expressed more clearly.
Suggested change
fn render_detail(detail:&Option<String>,fallback:Option<&str>){
letmut string = match*detail {
Some(ref string) => string.as_str(),
None => "",
};
if string.is_empty(){
ifletSome(fallback) = fallback {
string = fallback;
}
}
fn render_detail(detail:Option<&str>,fallback:Option<&str>){
let detail = detail.unwrap_or_default();
let fallback = fallback.unwrap_or_default();
let string = if detail.is_empty(){ fallback }else{ detail };
To expand on (1) a bit: Option<&T> is strictly more general than &Option<T>; there is nothing you can do with the latter that you couldn't do with the former, but &Option<T> requires you to actually have an Option<T> somewhere that you can take a reference of.
Similarly, there's no reason to use &String over &str. &str will let you do anything that &String would, but you don't need an owned String to use it.
Combining the two, you should use Option<&str> over &Option<String>. At the call site you can use .as_deref() to get exactly the type you need.

Fair point, but I will do this change in a separate PR. I am simply copying the existing function from dif_upload.rs in this PR

Oh, I didn't realize this was existing code.

loewenheim · 2024-12-05T16:02:57Z

 fn server_options(&self) -> &ChunkServerOptions;
+
+ /// Uploads the given chunked objects to the server.
+ fn upload_chunked_objects<T>(self, chunked: &[Chunked<T>]) -> Result<(Vec<DebugInfoFile>, bool)>


I wouldn't do this as a method on this trait; it seems to me that this should be a free function, although this is admittedly based on an aesthetic feeling.

Add functionality to the `ChunkOptions` trait, allowing the `ChunkServerOptions` to be obtained. With this change, `DifUpload` can no longer implement `ChunkOptions` directly, since it does not contain the server options, so we create a new `ChunkedDifUpload` struct to implement `ChunkOptions` by acting as a container for the `DifUpload` and `ChunkServerOptions`. Also, we take advantage of the new functionality by refactoring `upload_difs_chunked` to take only a single argument, the `ChunkedDifUpload`. The upload methods now take owned options structs, since an upload should only be performed once.

The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-9 branch from a661c6c to 6203e7aCompare December 5, 2024 15:34

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-10 branch from d4736a9 to e4cd295Compare December 5, 2024 15:34

szokeasaurusrex requested a review from loewenheim December 5, 2024 15:34

szokeasaurusrex changed the title ~~ref: Extract general chunk uploadin logic from upload_difs_chunked~~ref: Extract general chunk uploading logic from upload_difs_chunkedDec 5, 2024

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-10 branch from e4cd295 to 8caf2b4Compare December 5, 2024 15:36

szokeasaurusrex mentioned this pull request Dec 5, 2024
ref(dif): Add ability to get server options from ChunkOptions#2302
Closed

loewenheim reviewed Dec 5, 2024
View reviewed changes

szokeasaurusrex added 2 commits December 6, 2024 14:39

ref: Extract general chunk uploading logic from upload_difs_chunked
73ec38e
The `upload_difs_chunked` function contains some code which is specific to uploading difs, and some code which is general to uploading chunked objects. This change extracts the code that is generic to chunked objects

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-9 branch from 6203e7a to d923964Compare December 6, 2024 13:39

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-10 branch from 8caf2b4 to 73ec38eCompare December 6, 2024 13:40

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-9 branch from d923964 to cf02c17Compare December 16, 2024 15:28

szokeasaurusrex marked this pull request as draft December 16, 2024 15:31

szokeasaurusrex force-pushed the szokeasaurusrex/proguard-upload-9 branch from cf02c17 to 5a78717Compare December 16, 2024 15:38

Base automatically changed from szokeasaurusrex/proguard-upload-9 to masterDecember 16, 2024 15:49

szokeasaurusrex closed this Dec 16, 2024

szokeasaurusrex deleted the szokeasaurusrex/proguard-upload-10 branch December 16, 2024 15:55

szokeasaurusrex mentioned this pull request Dec 16, 2024
ref(chunks): Extract upload logic from upload_difs_chunked#2316
Merged