-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
UI: Fix empty item on kv list #22838
Conversation
@@ -138,13 +138,23 @@ export default class StoreService extends Store { | |||
return resp; | |||
} | |||
|
|||
forceUnload(modelName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting find!
@@ -46,9 +46,15 @@ export default class KvSecretsListRoute extends Route { | |||
}); | |||
} | |||
|
|||
getPathToSecret(pathParam) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
much cleaner, thank you!
@@ -24,92 +22,21 @@ export default class SecretDeleteMenu extends Component { | |||
|
|||
@tracked showDeleteModal = false; | |||
|
|||
@maybeQueryRecord( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When navigating from the details page back to the list in kv v1, the console was erroring with
Cannot create a new tag for `<model::capabilities:undefined>` after it has been destroyed
Finally tracked it down to these not tearing down gracefully, so I moved the capabilities to the model instead which is our latest pattern
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the secret-edit
component also uses maybeQueryRecord
so something to be aware of if we notice that error further. Interesting that it's also used in lazy-capabilities
which is used a bunch but maybe it's ok when used on a model since they aren't torn down as frequently as components.
) | ||
secretSoftDataPath; | ||
@alias('secretSoftDataPath.canUpdate') canSoftDeleteSecretData; | ||
get canUndeleteVersion() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This component should actually go away soon, so to simplify the changeset I just made these all getters of the same name
Build Results: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great working grinding this one out and finding a work around 👏. I left a few comments and questions, nothing blocking.
@@ -24,92 +22,21 @@ export default class SecretDeleteMenu extends Component { | |||
|
|||
@tracked showDeleteModal = false; | |||
|
|||
@maybeQueryRecord( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the secret-edit
component also uses maybeQueryRecord
so something to be aware of if we notice that error further. Interesting that it's also used in lazy-capabilities
which is used a bunch but maybe it's ok when used on a model since they aren't torn down as frequently as components.
this.unloadAll(modelName); | ||
this.forceUnload(modelName); | ||
// Hack to ensure the pushed records below all get in the store | ||
this.peekAll(modelName).length; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing this is necessary but since there is already a peek in the forceUnload
method it has to be done again after unloadAll
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I just sprinkled them around because I saw lots of test failures when I tried to minimize these. Hoping we can remove after upgrade.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought but I wonder if someone else ends up doing the next upgrade if it will be clear what can be removed as part of these workarounds? Maybe some extra annotations like remove after upgrade to Ember Data 4.12 would be helpful so we don't have extra peeks etc. hanging around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Added comments about removing once we upgrade to 4.12
test('no ghost item after editing metadata', async function (assert) { | ||
await visit(`/vault/secrets/${this.backend}/kv/edge/directory`); | ||
assert.dom(PAGE.list.item()).exists({ count: 2 }, 'two secrets are listed'); | ||
await click(PAGE.list.item('two')); | ||
await click(PAGE.secretTab('Metadata')); | ||
await click(PAGE.metadata.editBtn); | ||
await fillIn(FORM.keyInput(), 'foo'); | ||
await fillIn(FORM.valueInput(), 'bar'); | ||
await click(FORM.saveBtn); | ||
await click(PAGE.breadcrumbAtIdx(2)); | ||
assert.dom(PAGE.list.item()).exists({ count: 2 }, 'two secrets are listed'); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me! This PR touches some of the KV removal work that's still hanging in the wind. When this is merged I'll go ahead and update that sidebranch.
There is a bug in our version of ember-data (4.11.x) where after editing a record, going to the list page would result in a ghost record because
unloadAll
wasn't unloading everything properly. As part of the investigation I found a couple other issues that I cleaned up as well.Replication steps for initial issue:
We decided not to upgrade to ember-data@4.12 at this time (the version which has a fix), because after upgrade other tests were failing with
expected stable identifier
issues, and the upgrade requires store configuration which we didn't want to rush to get in before code freeze without adequate testing.