OpenGEOEngineering · 3 min read
Using available results before a Job is complete
Answers in a monitoring batch may finish at different times. Review the answers that are already available, but do not treat them as the entire observation window while work is still running. OpenGEO separates execution progress in Job status from result availability in result_state.
202 means the request was accepted
Keep the Job ID returned by creation. Query that same Job and its items. A successful HTTP request does not mean monitoring is complete, and a request timeout does not mean the Job failed. Use backoff, request timeouts and an overall waiting limit instead of creating another batch when a query takes too long.
Prefer: wait=N is a waiting preference for one request. The CLI --wait option does not start a polling loop. Continue querying with the returned ID.
Choose what to do with partial results
partial means some results are available. Read items before deciding whether to wait for the remaining work. If coverage is sufficient, request finalize-partial and use cancel_remaining=true to stop unfinished work. Confirm finalization from the returned state.
Use cancel when you only want to stop remaining execution. Cancellation does not delete completed answers or turn the Job into a complete success. Keep the partial-result label for finalized_partial. After cancelling, read the state and saved results again. On a state conflict, query the original Job rather than submitting again.
Show the scope alongside results
Show Job status, completed and total samples, and the number of observations actually loaded before presenting metrics. A single result page is not the total task progress, and the valid-sample ratio is not a completion rate. Keep retrieved sources separate from explicit answer citations.
Failure is not a zero mention rate
Keep HTTP errors, failed Jobs and unavailable fields distinct. Not requested, unsupported, temporarily unavailable, parsing failure and withheld public content must not all become "brand not mentioned". For diagnostics, keep the Job ID, safe request ID and error code. Exclude credentials and complete private responses from feedback.
When replaying a creation request after a network interruption, keep the same request body and Idempotency-Key. Follow Retry-After when rate-limited. Correct invalid requests or permissions first; do not silently switch platforms or reduce capabilities. If submission status is unknown, inspect the original task before deciding what to do next.
Practice locally before using a live environment
Dynamic job_mock_* tasks advance to success by deterministic rules; they do not simulate live partial results. Fixed job_demo_* fixtures return example write responses without a persistent state machine. The workbench is a read-only simulated preview. This guide explains contract and client decisions, not live actions in the UI.
The developer guide covers partial results, failures and retries. OpenAPI remains the source of truth for fields. Complete the local CLI tutorial first, then verify cancellation, finalization and result association in your own controlled test environment.