Repository navigation
Fix persistence provider bugs affecting new user logins - #475
Conversation
|
Also fixes #446 |
7d38937 to
b1603d1
Compare
- createIfMissing() called this.create(model) to persist a newly created namespace's folder object, which only exists on MCWSPersistenceProvider. MCWSUserContainerProvider inherits createIfMissing() but never implemented create(), so a brand-new user's namespace was created in MCWS but its folder object was never persisted, throwing "this.create is not a function". Persist directly through the already-in-scope namespace handle instead. - persistenceNamespaceKeys was derived only from non-user namespace configs, so a user's leaf folder (e.g. s6a_users-clgarcia) was only claimed by MCWSPersistenceProvider.appliesTo() when a differently- configured shared namespace happened to share the same key prefix. Derive it from all namespace configs instead; the user container node stays excluded via the existing invalidNamespaceKeys exact- match check. - MCWSPersistenceProvider caches its namespace list for the lifetime of the provider instance. When a second user's namespace is created in a different session after the first session's cache was already populated, the first session never finds it and throws a plain TypeError, surfacing as an "Error: <keystring>" placeholder object in the tree until the page is reloaded. Refresh the cache once on a lookup miss before giving up.
b1603d1 to
93b1c77
Compare
| return namespace.key === persistenceSpace; | ||
| }); | ||
|
|
||
| if (!persistenceNamespace) { |
There was a problem hiding this comment.
always better to check for existence and not a truthy statement
There was a problem hiding this comment.
Is that supposed to be the plan? cause we have ! everywhere in here lol
There was a problem hiding this comment.
I think this is ok, we definitely do this elsewhere, even though it's not the best way to go about it. But, I will update it to be if (persistenceNamespace === undefined) to be more clear. We only act if it's undefined.
There was a problem hiding this comment.
yes we do this elsewhere but we probably shouldn't in most cases
|
@jvigliotta , @mudinthewater , i added a couple of comments but this looks good otherwise. good job |
|



createIfMissing() called this.create(model) to persist a newly created namespace's folder object, which only exists on MCWSPersistenceProvider. MCWSUserContainerProvider inherits createIfMissing() but never implemented create(), so a brand-new user's namespace was created in MCWS but its folder object was never persisted, throwing "this.create is not a function". Persist directly through the already-in-scope namespace handle instead.
persistenceNamespaceKeys was derived only from non-user namespace configs, so a user's leaf folder (e.g. s6a_users-clgarcia) was only claimed by MCWSPersistenceProvider.appliesTo() when a differently- configured shared namespace happened to share the same key prefix. Derive it from all namespace configs instead; the user container node stays excluded via the existing invalidNamespaceKeys exact- match check.
MCWSPersistenceProvider caches its namespace list for the lifetime of the provider instance. When a second user's namespace is created in a different session after the first session's cache was already populated, the first session never finds it and throws a plain TypeError, surfacing as an "Error: " placeholder object in the tree until the page is reloaded. Refresh the cache once on a lookup miss before giving up.
Fixes #205