Common Error Messages

From HTTP codes to Platform BadRequest errors, make sense of the errors that are blowing up your code

Error messages and error codes are intended to be descriptive such that users will gain insight into why their code is failing. Of course, having a baseline understanding of error messages and error codes can be extremely helpful in debugging code and interpreting failures.

General Error Messages

These error messages may present themselves as Python Exceptions, HTTP Responses, or Tasks Errors.

Output width or height is less than 1 pixel

This error can come from any API that takes a GeoContext to pull imagery off of the DL Platform. Most often, the cause is a mismatch between resolution and Coordinate Reference System (CRS). The error message tells users the size of the requested AOI in relation to the specified resolution. For instance:

BadRequestError: Error with request:
{"message":"Output width or height is less than 1 pixel: width=0.5001800667553653 height=0.5001148833283489","status_code":400}

For reference, dl.Raster.ndarray was called with these arguments:

This occurs when the requested resolution is larger than the AOI (e.g. a 10x10 meter AOI requested with 100 meter resolution), sometimes caused by the AOI resolution being defined in a different unit than expected (for instance, degrees vs. meters). Click here to see an example solution, posted on GIS Stack Exchange. In this GIS Stack Exchange example, the resolution of the GeoContext is re-assigned such that it's equal to the desired resolution, but in units of degrees. 

Requested raster too large

This error will occur when attempting to rasterize (pull pixel values for) too much data. For instance:

BadRequestError: Error with request:
{"message":"Requested raster too large: 6.9GB > 5.0GB","status_code":400}

For reference, dl.Raster.ndarray was called with these arguments:

See the Quotas & Limits Guide for other Raster request limits. Try your query over a smaller AOI or a coarser spatial resolution. 

Image or search geometry has an invalid shape

Invalid geometries will cause this error. For instance:

BadRequestError: {"errors": [{"status": "400", "detail": "Image or search geometry has an invalid shape: invalid_shape_exception: Self-intersection at or near point [-105.86975097656249,36.94550173495345,0.0]"}]}

In this example, the geometry had a self-intersection and needs to be corrected before pulling data from the DL Platform.

minx >= maxx in given bounds

This error occurs when the geometry supplied to the Platform does not have an extent (e.g. Point, Linestring). The full error looks like this:

ValueError: minx >= maxx in given bounds, should be (minx, miny, maxx, maxy)

This error message indicates that the shape's minimum x-axis value is the same or greater than the maximum x-axis value. In this case, consider defining a GeoContext another way or buffering the shape using Shapely.

Python Errors & Exceptions

The descarteslabs Python client makes use of standard Python exception handling to surface errors to users. Some common errors users may encounter are:

  • Could not find client_id: This error message indicates that the local environment (laptop, VM, Workbench) is not authenticated with DL Platform APIs. Learn about making sure Workbench is authenticated in this article. For other environments, see the Authentication section of the docs.
  • JobOOM or ERROR_OOM: Workflows may present an Out Of Memory (OOM) error for some computations. The error message "Job ran out of memory; please use fewer data in your job by decreasing the resolution or the size of your spatiotemporal AOI" indicates that decreasing the time period of the analysis or the spatial extent of the AOI will help.

    HTTP Error Codes

    Because the descarteslabs Python client makes requests to the DL Platform via REST APIs, users may encounter HTTP error codes surfaced by the Platform. The HTTP error codes users see are well-defined and detailed in Mozilla's guide here. Generally speaking, HTTP error codes are:

    • 4XXs (400-499): Client (user) made a bad request. Some common 4XX error codes are:
      • 429: Too Many Requests error. A 429 error message means that a rate limit has been surpassed on the DL Platform (or for another system to which requests are being sent). See the Quotas & Limits Guide in the docs for information on per-API rate limits.
      • 404: Not found error. The requested object does not exist.
      • 400: Bad request error. For some reason or another, the request does not make sense to the DL Platform. One common case, "Output width or height is less than 1 pixel", is described above.
    • 5XXs (500-599): Server (DL) ran into an issue.

    Workbench Errors

    Users may encounter errors when developing in Workbench. Those may include:

    • Kernel Restarting. The kernel appears to have died. It will restart automatically: This error is caused when the available memory to the kernel is eclipsed. Try stopping some running kernels and looking into the amount of data being pulled off of the Platform or from other sources.

    Tasks Errors

    Tasks can fail for a few reasons:

    • Build failure: Take a look at the build logs, which are retrievable from Monitor. Oftentimes, build failures occur when a dependencies could not be found or resolved. This can be due to a package passed to requirements that cannot be found on PyPI, conflicting package versions and dependencies, or failures in finding any modules users include from a local environment.
    • Out of memory errors: The memory keyword argument can be used to adjust the memory footprint given to each Task worker. Per-worker memory defaults to 2Gi, and can be increased to be large enough for most Tasks. Consider separating out Tasks that require more memory than most and running them in their own Task group where each worker is granted a larger memory footprint. Keep in mind that any code and data downloaded into a Task (imagery from the DL Platform, a model weights file, etc) will deplete the memory available to the Task.
    • Executable Failed errors: This is a low-level Linux error message that most frequently means the memory footprint needs to be increased via the memory keyword argument. Example: ExecutableFailedError: (-9, '/opt/src/executable/127fb5a8').
    • Timeouts: A Task can run for, at most, 24 hours. The default Task timeout is 30 minutes. If a Task takes longer than the timeout specified, the timeout needs to be increased to accommodate the processing. If this processing exceeds 24 hours, consider checkpointing progress and continuing in another Task.

    Read about Tasks retries in the docs.