Skip to content

Errs when invoked on partial clones #1092

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
icp1994 opened this issue Jun 22, 2023 · 9 comments
Closed
1 task done

Errs when invoked on partial clones #1092

icp1994 opened this issue Jun 22, 2023 · 9 comments
Labels
bug Something isn't working

Comments

@icp1994
Copy link

icp1994 commented Jun 22, 2023

Duplicates

  • I have searched the existing issues

Current behavior 😯

$ git clone --filter=blob:none https://github.com/sharkdp/fd
$ onefetch fd/
Error: sending on a closed channel

Expected behavior 🤔

I don't know if partial clones have some limitations which prevents onefetch from working so maybe erring is the expected behavior.

Steps to reproduce 🕹

No response

Additional context/Screenshots 🔦

No response

Possible Solution 💡

No response

@icp1994 icp1994 added the bug Something isn't working label Jun 22, 2023
@icp1994
Copy link
Author

icp1994 commented Jun 22, 2023

Possible duplicate/related #978. Also, onefetch 2.18.0

@spenserblack
Copy link
Collaborator

Would you be willing to try out an earlier version? I'm curious if this was introduced in the recently released version.

@icp1994
Copy link
Author

icp1994 commented Jun 22, 2023

Works with v2.17.1

@spenserblack
Copy link
Collaborator

Thanks for checking!

The fact that it was introduced in v2.18, along with this error

Error: sending on a closed channel

Makes me think that this was introduced with our new file churn metric.

@spenserblack
Copy link
Collaborator

spenserblack commented Jun 22, 2023

I'm thinking that maybe #1081 introduced this? 🤔 Not implying that the changes in that PR should be undone -- I think they're good changes, including the changes that result in this error being raised 🙂

.send errors were previously simply ignored by .send(foo).ok(), but now they're handled with .send(foo)?. I'm more used to concurrency in Go than Rust, so I'm a bit out of my depth here. But perhaps there can be an additional sender/receiver pair to send a stop signal, so that the sender knows that the receiver does not expect any more values? A bit less hack-y than ignoring errors on send attempts 🙂 The receiver seems to be dropped before the sender finishes sending.

Again, from (hobby-level) Go experience, it looks a bit weird to me that the receiver is in the coroutine, and the sender is in the outer scope that calls the coroutine. I'm more used to it being the reverse. With the receiver in the outer scope, you should be able to be more confident that it won't be dropped (closed) before the sender stops sending.

@icp1994
Copy link
Author

icp1994 commented Jun 22, 2023

d5f8621 is the last "good" commit. With the next commit 1955153 I get:

$ onefetch /fd
Error: Could not find blob for similarity checking

Caused by:
    An object with id 0da0e9c3963daf5e99f99d2adbf825ce15090c58 could not be found

Same with fd1d5f0 and finally after the following commit 09c4dc9 it shows the current error.

@spenserblack
Copy link
Collaborator

Thanks for bisecting and finding the exact commits!

@o2sh
Copy link
Owner

o2sh commented Jun 24, 2023

@icp1994
Copy link
Author

icp1994 commented Jun 25, 2023

Thanks! Tested locally, works as intended.

@icp1994 icp1994 closed this as completed Jun 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants