diff --git a/serverless/containers/reference-content/containers-limitations.mdx b/serverless/containers/reference-content/containers-limitations.mdx index 257cb9e872..9a8c691cb4 100644 --- a/serverless/containers/reference-content/containers-limitations.mdx +++ b/serverless/containers/reference-content/containers-limitations.mdx @@ -86,3 +86,20 @@ For example, if you build an image using an ARM CPU, such as Apple Silicon M ser You must ensure that you build your image to target `amd64` architecture, to acheive this there are multiple solutions: * You can use the following Docker command: `docker buildx build --platform linux/amd64 .`, or * You can use an Instance with `amd64` architecture to run your builds. + +## Versioning and rollback + +Scaleway Containers do not currently support versioning or automatic rollback mechanisms. +However, in the event of a failed deployment, the previously deployed version of the container will continue to handle +incoming requests for up to 24 hours. After this period, the container in error will be deleted, and requests will no +longer be served until a successful deployment is made. This ensures temporary service continuity, but it is important +to monitor and resolve deployment issues promptly, as the fallback is not intended to provide long-term version control +or rollback capabilities. + +Below is an example than illustrates this behavior: + +* Time +0H: The first container is deployed and works correctly. +* Time +1H: The container is redeployed, but the deployment fails, and the container ends up in an error state. +* Time +2H: Despite the failed deployment, the first container is still handling incoming requests. +* Time +25H: The 24-hour window expires, and both the first working container and the failed container are removed, +leading to service disruption until a new successful deployment is made. diff --git a/serverless/containers/troubleshooting/common-errors.mdx b/serverless/containers/troubleshooting/common-errors.mdx index c004b7dc70..83931eceb9 100644 --- a/serverless/containers/troubleshooting/common-errors.mdx +++ b/serverless/containers/troubleshooting/common-errors.mdx @@ -46,3 +46,13 @@ This issue can happen for the following reasons: ### Possible solutions Make sure that you did not exceed the maximum number of allowed namespaces with the [Scaleway console](https://console.scaleway.com/) or with the [API](https://www.scaleway.com/en/developers/api/serverless-containers/#path-namespaces-list-all-your-namespaces). + +## Container stopped working several hours after a redeploy + +### Cause + +The new deploy failed, and the [fallback mechanism has been triggered](/serverless/containers/reference-content/containers-limitations/#versioning-and-rollback). + +### Possible solution + +Identify the element that caused the deployment to fail, fix the error, and deploy the container again. diff --git a/serverless/functions/reference-content/functions-limitations.mdx b/serverless/functions/reference-content/functions-limitations.mdx index 36a6614ce0..61ee48c16c 100644 --- a/serverless/functions/reference-content/functions-limitations.mdx +++ b/serverless/functions/reference-content/functions-limitations.mdx @@ -55,3 +55,20 @@ To ensure the proper functioning of the product, we restrict the use of certain * **465**: Due to potential abuse (spam), no outbound traffic is allowed through this port, except from Scaleway Transactional Email SMTP servers. * Reserved environment variables: * `SCW_*`: Reserved for product configuration (for example: token validation). + +## Versioning and rollback + +Scaleway Functions do not currently support versioning or automatic rollback mechanisms. +However, in the event of a failed deployment, the previously deployed version of the function will continue to handle +incoming requests for up to 24 hours. After this period, the function in error will be deleted, and requests will no +longer be served until a successful deployment is made. This ensures temporary service continuity, but it is important +to monitor and resolve deployment issues promptly, as the fallback is not intended to provide long-term version control +or rollback capabilities. + +Below is an example than illustrates this behavior: + +* Time +0H: The first function is deployed and works correctly. +* Time +1H: The function is redeployed, but the deployment fails, and the function ends up in an error state. +* Time +2H: Despite the failed deployment, the first function is still handling incoming requests. +* Time +25H: The 24-hour window expires, and both the first working function and the failed function are removed, +leading to service disruption until a new successful deployment is made. diff --git a/serverless/functions/troubleshooting/common-errors.mdx b/serverless/functions/troubleshooting/common-errors.mdx index 4cf775e47d..e308928d89 100644 --- a/serverless/functions/troubleshooting/common-errors.mdx +++ b/serverless/functions/troubleshooting/common-errors.mdx @@ -97,4 +97,14 @@ This issue can happen for the following reasons: ### Possible solutions -Make sure that you did not exceed the maximum number of allowed namespaces with the [Scaleway console](https://console.scaleway.com/) or with the [API](https://www.scaleway.com/en/developers/api/serverless-functions/#path-namespaces-list-all-your-namespaces). \ No newline at end of file +Make sure that you did not exceed the maximum number of allowed namespaces with the [Scaleway console](https://console.scaleway.com/) or with the [API](https://www.scaleway.com/en/developers/api/serverless-functions/#path-namespaces-list-all-your-namespaces). + +## Function stopped working several hours after a redeploy + +### Cause + +The new deploy failed, and the [fallback mechanism has been triggered](/serverless/functions/reference-content/functions-limitations/#versioning-and-rollback). + +### Possible solution + +Identify the element that caused the deployment to fail, fix the error, and deploy the function again.