Skip to content

Conversation

@jvigliotta
Copy link
Collaborator

@jvigliotta jvigliotta commented Jun 4, 2025

closes #240

If there's an error getting an object that is NOT a 404, then we return an error object, similar to how we return a missing object for missing... objects (in our case for user folders a 404 means we create the root object:

async createIfMissing(namespaceDefinition, userId) {

This addition of returning the error object, allows us to not try to save a missing object caused from a network error (no internet for example) in the case it's from an older persistence store that had folders on the backend, but no root object :

Also added a retry loop. It will retry 3 times to get the object in 2, 4 and 8 second intervals at which point it will return the error object if there is still a network error.

@jvigliotta jvigliotta requested a review from davetsay June 4, 2025 00:15
@jvigliotta jvigliotta requested a review from davetsay June 5, 2025 21:47
Copy link
Collaborator

@davetsay davetsay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, but I just want to make sure you see this before approved.

I thought you said the unknown type check never happens, because the tree loading blocks the creation of the unknown object? If thats the case, maybe we shouldn't be coding for something that will never happen? If it does happen though, should we create an object Type to handle this, or maybe use another comparator such as object.unresolvedRequest===true (property name could need work), rather than a string check?

@jvigliotta
Copy link
Collaborator Author

This looks good, but I just want to make sure you see this before approved.

I thought you said the unknown type check never happens, because the tree loading blocks the creation of the unknown object? If thats the case, maybe we shouldn't be coding for something that will never happen? If it does happen though, should we create an object Type to handle this, or maybe use another comparator such as object.unresolvedRequest===true (property name could need work), rather than a string check?

The check happens, the object never makes it to the UI though. The check is what prevents the request from going out, so it's working in that regard. Let's chat about the check.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jun 9, 2025

@jvigliotta jvigliotta merged commit 14a1028 into main Jun 10, 2025
3 checks passed
@jvigliotta jvigliotta deleted the omm-240 branch June 10, 2025 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5.3 user root persistence migration can indadvertantly delete user roots

3 participants