Dispatched urls can lead to problems with data that hasn't loaded
Bug #1340417 reported by
j.c.sackett
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| juju-gui |
Triaged
|
High
|
Unassigned | ||
Bug Description
The GUI has urls that can load various components (e.g. /inspector/
We address this now where it's cropped up by either bailing out of the url and asking the user to try again, since data will be loaded when the user can react, or by entering various fragile retry-loops.
A better solution to the root problem is needed.
| description: | updated |
| Changed in juju-gui: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| summary: |
- Dispatched urls can lead to problems with data that hasn't loads + Dispatched urls can lead to problems with data that hasn't loaded |
Revision history for this message
| j.c.sackett (jcsackett) wrote | #1 |
Revision history for this message
| j.c.sackett (jcsackett) wrote | #2 |
To post a comment you must log in.
The better fix for this after Jeff and I looked into this is to break up the inspector rendering into two steps. The first loads the inspector UI (absent the service/charm info), the second populates the info.
Much as we do now, we check to see if we have model and charm data; if we do, we proceed directly to the second stop. If not, we set up a function listening for the db.services and db.charms add signals, to check the db for the necessary info each time it's added. After a timeout, if no data is found, we can abort much as we do now (send notification and close the inspector).
This function needs to detach itself from the db events once it finds the data it needs, and then proceed to the second rendering step.