Tauri image error popup

[ukarlsson]

Version

0.13.2

Operating System

macOS

Distribution Method

dmg (Apple Silicon)

Describe the issue

This popup comes up all the time for me since recent update.

It says

f6d45a630a194830bbddb22ac1d72f91: The reference did not exist a@tauri://localhost/_app/immutable/chunks/Icon.FmaqJgaA.js:1:940 fromError@tauri://localhost/_app/immutable/chunks/Icon.FmaqJgaA.js:1:1109 @tauri://localhost/_app/immutable/chunks/Icon.FmaqJgaA.js:1:1319

How to reproduce

No response

Expected behavior

No response

Relevant log output

No response

[Byron]

Thanks a lot for reporting!

It's probably something about how the UI intercepts backend errors - previously it must have (maybe unintentionally) ignored some of the errors that occurred, while now it will show all of them.

This error in particular is well known and seems to happen when the sidebar (with branch information) refreshes. It comes from gitoxide and I think it would help if the reference it tried to fetch was mentioned.

[ukarlsson]

I still get these popups all the time but they are slightly different now

[anirudhsama]

Thanks a lot for reporting!

It's probably something about how the UI intercepts backend errors - previously it must have (maybe unintentionally) ignored some of the errors that occurred, while now it will show all of them.

This error in particular is well known and seems to happen when the sidebar (with branch information) refreshes. It comes from gitoxide and I think it would help if the reference it tried to fetch was mentioned.

For me, it tries to fetch the same branch multiple times (main in my case). See the recording: https://cln.sh/W0Wdllx7

[Byron]

That's interesting! I wonder what's happening there that master doesn't exist, at least in that very moment. Having looked at the code, I'd think this error is genuine and not a false positive.

Something I could imagine happening here is that somehow the master branch is moved into packed-refs, and it's implemented in such a way that the loose ref is deleted before writing out the changes to packed refs. It seems absurd though and I don't think git2 would do that, or Git for that matter, nor do we use gitoxide to edit references if that should be buggy.

But at least it's a hint… as it also shows that this is about branches that GitButler usually doesn't write, I think. CC @krlvi , as I am a bit out of ideas here.

[ukarlsson]

These are the console logs @Byron

[Error] ipc->get_branch_listing_details: {"projectId":"86f458a6-afd9-4832-a536-a7e6efec8daf","branchNames":["uk/migration-docs-update"]} (2)
Error: The reference 'master' did not exist
Object
	(anonymous function) (user.Ch_KofWw.js:4:244)
	(anonymous function) (ipc.BH79wg8L.js:1:1135)
[Error] 079d36665acd41e3b6339754319690f2: The reference 'master' did not exist

s@tauri://localhost/_app/immutable/chunks/ipc.BH79wg8L.js:1:734
fromError@tauri://localhost/_app/immutable/chunks/ipc.BH79wg8L.js:1:903
@tauri://localhost/_app/immutable/chunks/ipc.BH79wg8L.js:1:1111

	(anonymous function) (user.Ch_KofWw.js:4:244)
	X (app.DbAX_1i9.js:6)
	(anonymous function) (app.DbAX_1i9.js:3:484)
[Error] Unhandled Promise Rejection: Error: The reference 'master' did not exist
	(anonymous function) (remoteBranches.BVrp5G9j.js:1:18000)

[ukarlsson]

It is triggered by not having master branch locally, you can reproduce with

git branch -D master

It gets created if I switch to it

git checkout master

I never use master branch locally so it should not be needed I think, it should use origin/master instead

[Byron]

That's interesting - then the question is why it would search for master in the first place.

Are you saying that origin/master exists, i.e. a tracking branch, but no local branch for it?

When doing the initial branch listing, maybe there is some logic that affects the name, and turns origin/master into master?

I took a quick look and overall, the logic doesn't seem to conclude from a tracking branch to a local one that it didn't see. However, there is the notion of a branch 'identity' which would strip the remote name from a short name, so origin/master (which it would see in your case) has an identity called master

If there was some frontend code that looks for the 'identity' of a branch, then I think we could see this result. However, I didn't find evidence that this is done in the frontend.

However, simply by deleting a branch that also has a local tracking branch, the issue is easily reproduced.

Who wants to fix it? @estib-vega maybe :)?

[estib-vega]

Hey @ukarlsson! Thanks yet again for reporting! It's very appreciated. I can take a look.

Just a little shot-in-the-dark question: Does your repository have multiple remotes?

[ukarlsson]

No it is a single remote repo. I confirmed that the issue emerges when I delete master branch, and it goes away when I create it.

[anirudhsama]

I'm facing the same behaviour as @ukarlsson. Single remote origin/main.

[estib-vega]

I think I found the culprit.

https://github.com/gitbutlerapp/gitbutler/blob/dcd6391c889e22bc0502829de5a1a831ecd50e90/crates/gitbutler-branch-actions/src/branch.rs#L459-L479

Here we're looking for a local branch that has the same name as the target. I don't fully understand why we need to do that, it seems we just the current tip commit as a fallback value.

@Byron Can you help me out with some context :)? My initial guess is that we could try to find the commit without getting the local branch at all

[Byron]

Great catch, @estib-vega!

And yes, now that we know that the default-target could have its local branch deleted, I think a viable fallback would be to detect that case and fallback to the commit that is stored with the default target.

try_find_reference() should exist for that :).

[estib-vega]

@Byron I think the solution needs to be a bit different: https://github.com/gitbutlerapp/gitbutler/pull/5295

In a nutshell: I think GitButler shouldn't care about the local "target" branch at all. It mostly doesn't but then in some places it references it but I believe this might be a mistake (correct me if I'm wrong).

A bunch more context if anyone is interested :)

I think this is why the sometimes the branch listings in the side-bar were a bit broken (in some cases).

There are key parts to this:

• The remote target (e.g. origin/main)
• The local "target" branch (e.g. main)
• The GitButler workspace branch (gitbutler/workspace)

Whenever we integrate upstream, what GB does is to effectively move gitbutler/workspace to the tip of origin/main. The local "target" will never be updated by GitButler and that's why comparing to it would sometimes show multiple commits and authors on the side-bar listings.

To fix that we need to compare against the tip of origin/main for the branches not on the workspace and against gitbulter/workspace (target.sha) for the ones that are.

[anirudhsama]

Just updated to 0.13.7 and this issue has been fixed 🎉