Add additional batch job timestamps #556
Conversation
… the corresponding STAC results. #542
m-mohr
requested review from
soxofaan,
clausmichele,
dthiex and
ValentinaHutter
|
An useful addition to track the time a batch job takes without workarounds, thanks! By the way, to add those field to the STAC results we would have to use this extension right? https://github.com/stac-extensions/timestamps/ |
|
@clausmichele Only for expires, all others are not defined in that extension. Due to slightly different meaning, it could also be omitted. |
Co-authored-by: Serge Croisé <[email protected]>
Co-authored-by: Serge Croisé <[email protected]>
openapi.yaml
Outdated
| type: string | ||
| format: date-time | ||
| description: >- | ||
| Time until which the assets are accessible, in UTC. Formatted as |
There was a problem hiding this comment.
| Time until which the assets are accessible, in UTC. Formatted as | |
| Time until which the assets (e.g., batch job results) are available for download, in UTC. Formatted as |
There was a problem hiding this comment.
That might be a bit misleading.
expires can be used for when the signed URLs expire and also for when the data is deleted, I think. That's why I chose accessible. The addition in brackets is fine though.
| Time until which the assets are accessible, in UTC. Formatted as | |
| Time until which the assets (e.g., batch job results) are accessible, in UTC. Formatted as |
Maybe we should actually split into expires and unpublished, i.e.
- expires: signed URL expiry (if relevant here?) but in STAC it's that...
- unpublished: when the data gets deleted
There was a problem hiding this comment.
ok good point.
But indeed, we should separate the expiry of signed URLs (which can be refreshed easily) and the expiry for download availability in general (which is final and non-recoverable).
I think the general availability of results should be a global property on GET /jobs/{job_id} or GET /jobs/{job_id}/results, while the signed URL expiry should be closer to the links/URLs themselves (e.g. different signed URLs within the same resource might have different expiry for some advanced reason)
There was a problem hiding this comment.
Okay, I've updated the PR accordingly:
- Clarified usage of expires, removed from the batch job info endoint
- Added unpublished to batch job info endpoint and batch job results
- Added all the timestamps also to the Collection-typed result response, previously it was only defined in the Item-typed result response
Co-authored-by: Serge Croisé <[email protected]>
Implements #542
Reasoning for the fields based on the discussion in #542 and the existing fields (created, updated, expires):
All properties are optional except for created.
created, updated and expires are somewhat aligned in their meaning with STAC. queued and started don't exist in STAC.