Brews removed from Google Drive cannot be deleted from "My Brews" page. about homebrewery

[G-Ambatte]

This is a strange one... I just went through the process using one of my old brew stored on Google Drive, and everything works as expected, so there must be something strange happening.

deleteBrew specifically looks for a HB 02 error response from getBrew (which can be summed up as getBrew failed with googleError.reason:'notFound') and attempts to delete the stub from the HB MongoDB (HomebrewModel.deleteOne({ editId: id })). We should see in the logs the warning No google brew found for id ${googleId}, the stub with id ${id} will be deleted.

Alternatively, somehow the brew might still be showing up in Google Drive because the information being returned to the UserPage is incorrect - if a file somehow was returning an editId that didn't match it's own file ID? I'm not sure how that could happen but it's possible that the input to the UserPage is incorrect somehow and the

Possible causes:

• the getBrew is not returning a HB 02 error
• the deleteOne edit ID is not actually found in the HB database
• the UserPage is getting incorrect data somehow

[G-Ambatte]

Inspecting the user-provided link (https://homebrewery.naturalcrit.com/share/1-gwB3caElgqoqwHmQA0guHbD2P56EoBQ1wNbCNj9DJ-D) with the React Component Inspector shows that the returned error definitely has HBErrorCode: "02", which is the expected result. To my mind, this eliminates getBrew as the source of the issue.

[G-Ambatte]

Without access to the specific edit and share IDs for the file, I can immediately see that the shareID is much longer than a stubbed brew. So either the shareID is coming from Google itself - which would be strange, as the user reports that the brew is already deleted there - or there is a very long share ID in the HB MongoDB somewhere.

[G-Ambatte]

I was able to reproduce this issue by using Google Drive's permissions settings to set the file access to Restricted, blocking the Service Account. The file was still listed on the User Page, as the listGoogleFiles uses the User auth token.
Attempting to access the file resulted in a 404 / HB02 error, as the getBrew uses the Service Account auth token.
Attempting to delete the file from the User Page resulted in the Share and Edit links becoming very long (as the Mongo stub with the short IDs no longer exists), exactly like the example provided by the user.

[G-Ambatte]

I believe that we can prevent this issue from re-occurring by modifying the getBrew function to take an auth token parameter, defaulting to the Service Account token, and then having the deleteBrew function pass the User token. This will ensure that the authentication token used throughout the entire process is consistent.

[calculuschild]

Have we communicated to the user that we think their brew does exist on their google drive somewhere? My understanding from their post is that the brew is lost and unrecoverable.

We can still fix the deleting issue, but if this is really just due to sharing settings, their brew is still out there somewhere and they probably want it.

[G-Ambatte]

The following has been posted to Reddit for 11 days now:
https://www.reddit.com/r/homebrewery/comments/158k1z5/brew_with_missing_google_drive_file_cannot_be/jtkzkpu/

I've managed to reproduce this exact situation, in the following conditions:

• the file still exists somewhere in the linked Google Drive account (even in the Bin)
• the sharing permissions are set to Restricted, not Anyone with the link can edit

This is because the list of Google files is generated using the user's Google account authentication, but the actual access of the file for viewing, editing, and file deletion is instead performed by the Homebrewery Service Account.

I wonder if there is potential value in also adding a link to the Google file in the Brew item, so there is no opportunity for "I can't find my brew in Google Drive" or "my document is missing!"

[G-Ambatte]

I wonder if there is potential value in also adding a link to the Google file in the Brew item

PR #2969 is this change, it was a surprisingly simple change to make.