Snowpark Container Services troubleshooting

This topic discusses common issues and how you might resolve them.

Image registry

  • “invalid consent request” error received when accessing a public service endpoint.

    In the current implementation, Snowflake authenticates the current user using their default role. This error is probably because the user is using one of the privileged roles, such as ACCOUNTADMIN, SECURITYADMIN, or ORGADMIN, as their default role (see Blocking specific roles from using the integration). Use the ALTER USER command to change the default role for the user, and try again.

  • docker login authentication failure.

    Do not use an uppercase hostname in the docker login command and then use a lowercase hostname in the docker push, docker pull command. Docker CLI stores credentials with cased keys. Related Docker CLI issue.

  • docker push error: no Host in request URL.

    When interacting with Docker CLI, always replace the underscores in your account name in a URL with hyphens. Docker CLI will return an error if hostnames have underscores in them (even though cURL works). For example, the following Docker push specifies “my_acct” as the account name:

    docker push myorg-my_acct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/service_to_service
    
    Copy

    Docker returns this error:

    Get "https:/v2/": http: no Host in request URL.
    

    You can also use the SHOW IMAGE REPOSITORIES command to get a valid repository URL.

Compute pool

  • Suspended compute pool stuck in STOPPING state.

    Running services will prevent the compute pool from stopping. Suspend all remaining active services in the compute pool using the ALTER COMPUTE POOL command:

    ALTER COMPUTE POOL <pool_name> STOP ALL
    
    Copy

Service

  • A running service is no longer responding to requests (from a service function or a public endpoint). The service status changed from running to pending.

    This could be an indication of resource starvation on compute pool nodes. If your containers are resource-intensive (CPU/memory), you should explicitly specify resource requests in the service/job specification to prevent too many services/jobs being placed on a single node.

    In the current implementation, you can only specify memory requests.

    For example, if a node in the compute pool has 64 GB of RAM, requesting more than 32 GB for your service/job would guarantee that only one service or job can be running on a node at a time. For more information about the capability of each instance type, see CREATE COMPUTE POOL.

  • If you are submitting a request to the public endpoint for the service, do not use double quotes in the HTTP authentication header.

Service functions

  • Service function timeout and duplicate execution issues.

    If a single service function invocation takes longer than 30 seconds, Snowflake retries the function, and after a few retries, the function fails with a timeout error. You might get unexpected results if the function implementation in the container is not idempotent. Consider using asynchronous execution by returning a different HTTP code (202), which allows a longer timeout. For more information, see Asynchronous Remote Service.

  • Invoking a service function returns a “service not found” error, but the SHOW SERVICES command shows that the service exists.

    Check whether the service associated with the service function was dropped (DROP SERVICE) and recreated (CREATE SERVICE). If so, you need to recreate the service function to point it to the new service.