Enum JobState
- Namespace
- DatabentoDotNet.Historical
- Assembly
- DatabentoDotNet.Historical.dll
The stage a batch job has reached.
public enum JobState- Extension Methods
Fields
Done = 4The job has finished and its files are available to download.
Expired = 5The job has passed its ExpirationTimestamp and its files are no longer downloadable.
Finalizing = 3The data is ready and the job's files are being packaged.
Processing = 2The job is being processed.
Purged = 6The job's files have been deleted.
Queued = 1The job is queued for processing.
Received = 0The API has accepted the job but has not yet queued it for processing.
Remarks
Port of upstream's JobState (batch.rs:422-432), widened from four members to
seven — and the three extra ones are not speculative. #39 asked the API what it accepts by
sending batch.list_jobs?states=bogus, and its 400 enumerates them:
['received', 'queued', 'processing', 'finalizing', 'done', 'expired', 'purged'].
Upstream models queued, processing, done and expired only.
The three it is missing are a live defect there, not a cosmetic gap. Upstream's
JobState derives its deserializer from FromStr, which errors on
any spelling it does not know — and batch.list_jobs returns every job the
account has. So one job sitting in received or finalizing, which is where a job
spends its first seconds, fails the deserialization of the whole listing rather than of that
one element. Porting the four faithfully would have reproduced an outage that happens to be
invisible in a test suite whose fixtures are all done.
The order is the API's own, which is also the lifecycle order: a job is received, queued, processed, finalized and done, and later expires and is purged. Nothing on the wire carries the numeric value — BatchWireStrings holds the only spellings that matter — so the ordering is documentation rather than protocol.