readthedocs
API: add build detail stale state
On the backend modeling, there is an attribute to describe a build that is stuck in
a triggered state for too long: Build.is_stale
It doesn't seem there is something comparable on the build detail API. I only see
a build that is described as Build.is_stale with a triggered state/status:
state Object { code: "triggered", name: "Triggered" }
"Stale" is not a state itself. It's basically a build in triggered state that has been in that state for more than 5 minutes: https://github.com/readthedocs/readthedocs.org/blob/0b09fda4be8a2e955fe7041324217a3f6ed42b15/readthedocs/builds/models.py#L951-L954
You should probably move that logic into the frontend, since it's the only place where it's used.
I want to avoid implementing and duplicating backend logic in the frontend, to keep the frontend code footprint as minimal as possible.
Yeah. I'm saying that we should remove this logic from the backend and put it in the frontend because it's not used in the backend and you are having issue to access to this logic from there
Gotcha, I figured this was used for build cleanup on the backend as well. If it's just frontend, it can be moved.
Generally, I am leaning more towards including everything we can from the backend. Similar to the django-ism of removing logic from templates, there is benefit to complexity in beefing up our API and avoiding front-end logic.
If the fontend is using the API to fetch all the Build data and display it there, I'd say we should move this two-lines logic to the frontend and remove it from the backend. Mainly, because otherwise we will be adding a field that does not exists on the model (it's not a state itself) into the API response. Also, the logic that define "stale" it's only used to show a small icon on the build list page currently and I doesn't not represent anything at a db level or Read the Docs code base level either. I personally think this type of logic is better to live in the frontend.