Change Details

Currently, due to some internal details, the reported status of a save code now can be strikingly strange for users. A visit can be reported succesfull and yet when browsing the origin, nothing is shown (due to replication lag). Internal details vary from db replication which can lag and due to how we compute internal the state of save code now. We need to investigate and try to simplify such status computations. We recently added new status from loaders which should allow to simplify and stay consistent across responses [1] Invariant: The api response from the webapp should stay the same [1] Something like: ``` 17:19 <ardumont> visit_status: not_found, failed, partial (debatable) -> failed 17:19 <ardumont> visit_status: full -> success 17:20 <ardumont> visit_status: si on a pas on fallback sur le status de la tache (scheduled, running, ...) ``` Related to T3361

Currently, due to some internal details, the reported status of a save code now can be strikingly strange for users. A visit can be reported succesfull and yet when browsing the origin, nothing is shown (due to replication lag). Internal details vary from db replication which can lag and due to how we compute internally the state of save code now. We need to investigate and try to simplify such status computations. We recently added new status from loaders which should allow to simplify and stay consistent across responses [1] Invariant: The api response from the webapp should stay the same [1] Something like: ``` 17:19 <ardumont> visit_status: not_found, failed, partial (debatable) -> failed 17:19 <ardumont> visit_status: full -> success 17:20 <ardumont> visit_status: si on a pas on fallback sur le status de la tache (scheduled, running, ...) ``` Related to T3361

Currently, due to some internal details, the reported status of a save code now can be strikingly strange for users. A visit can be reported succesfull and yet when browsing the origin, nothing is shown (due to replication lag). Internal details vary from db replication which can lag and due to how we compute internally the state of save code now. We need to investigate and try to simplify such status computations. We recently added new status from loaders which should allow to simplify and stay consistent across responses [1] Invariant: The api response from the webapp should stay the same [1] Something like: ``` 17:19 <ardumont> visit_status: not_found, failed, partial (debatable) -> failed 17:19 <ardumont> visit_status: full -> success 17:20 <ardumont> visit_status: si on a pas on fallback sur le status de la tache (scheduled, running, ...) ``` Related to T3361