-
Notifications
You must be signed in to change notification settings - Fork 5
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
Pending scenarios #50
Comments
I think we should show pending scenarios on the interface. Creating a
scenario may not be instantaneous, and it is confusing if a user creates a
scenario and subsequently sees nothing in the UI.
Access to the page of a pending scenario may not be necessary.
Periodically removing stalled processes seems like a good option. Let's
mark this as a future enhancement?
…On Thu, Mar 9, 2017, 09:17 Daniel da Silva ***@***.***> wrote:
When creating a new scenario, via new file, if the file upload is
interrupted (voluntarily or not) the scenario will become irrecoverable.
This happens because of how the api works:
- A scenario is created in the database with pending state
- A presigned url is sent to the user for file upload
- Once the file is uploaded the server will set the scenario state as
active.
If the file upload fails the scenario will exist in the database but it's
not possible to edit it for files can only be changed on creation. The
solution for the user is to create a new scenario and upload the file
again. The only annoyance is having to insert the form data again.
We should also hide pending scenarios from the interface for it is not
possible to so anything with them since they don't have files. We should
also block access to a page for a scenario in pending state. yay/nay?
This will lead to an potentially weird situation. If the user tries to use
a name attributed to a pending scenario, it will error for the name it's in
use (but not visible in the list).
The solution for this name problem would be to perform a database cleanup
every so often, where we remove any pending scenario which wasn't properly
setup.
Should we also remove these pending scenarios from the api list?
Thoughts @olafveerman <https://github.com/olafveerman>
cc @ricardomestre <https://github.com/ricardomestre>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#50>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAt24mJUI7_7vTnwqv9IJ3zgNclvWLVZks5rkBf_gaJpZM4MYNuA>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When creating a new scenario, via new file, if the file upload is interrupted (voluntarily or not) the scenario will become irrecoverable. This happens because of how the api works:
If the file upload fails the scenario will exist in the database but it's not possible to edit it for files can only be changed on creation. The solution for the user is to create a new scenario and upload the file again. The only annoyance is having to insert the form data again.
We should also hide
pending
scenarios from the interface for it is not possible to so anything with them since they don't have files. We should also block access to a page for a scenario inpending
state. yay/nay?This will lead to an potentially weird situation. If the user tries to use a name attributed to a pending scenario, it will error for the name it's in use (but not visible in the list).
The solution for this name problem would be to perform a database cleanup every so often, where we remove any pending scenario which wasn't properly setup.
Should we also remove these pending scenarios from the api list?
Thoughts @olafveerman
cc @ricardomestre
The text was updated successfully, but these errors were encountered: