-
Notifications
You must be signed in to change notification settings - Fork 6
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
Bugfix/agendapoint ordering #213
Conversation
It was pretty easy to get the db in an inconsistent state by cancelling the save/delete tasks halfway through. (for example by clicking outside the modal while the tasks were running). Because save and delete happen in steps (because of lacking support for cascading in ED) this could cause problems since child tasks are linked by default.
@@ -180,10 +181,15 @@ export default class AgendaManagerAgendaContextComponent extends Component { | |||
if(item.position !== index || previousItem !== previous) { | |||
this.setProperty(item, "position", index); | |||
this.setProperty(item, "vorigeAgendapunt", previous); | |||
const treatment = yield item.treatment; | |||
const treatment = yield item.behandeling; |
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.
yikes, does this mean the order of treatments was never correctly saved?
looks like it will always be set to null. Guessing that since we don't use it, it hardly changes much: https://github.com/lblod/notulen-prepublish-service/blob/5e95f3c3601e20b87c05b7f5e85938ce560da9ad/models/treatment.js#L31
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 is used here: https://github.com/lblod/notulen-prepublish-service/blob/5e95f3c3601e20b87c05b7f5e85938ce560da9ad/models/treatment.js#L75, so possible incorrect info when an extract is published
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 will mitigate most issues, so this can be merged.
Couple of remarks:
- I guess it would make more sense if we could block closing the modal until our tasks are done
- if a user closes the modal before these tasks are done, will the UI look ok to them (e.g. even though the tasks haven't finished yet will they see the correct info... I'm guessing yes).
probably fixes https://binnenland.atlassian.net/browse/GN-3037
It's hard to exactly reproduce the problem, but this pr solves 2 database inconsistency issues related to agendapoint ordering logic.
Imo the most likely cause was closing the modal while the update/delete tasks were still running.
Due to (once again) machty/ember-concurrency#161 this can easily cause inconsistent database state. (e.g. an agenda-item without treatment)