docs(serverless): add Versioning and rollback section (#3803)

* docs(serverless): add section Versioning and rollback in function and container limitations

* fix: review changes

* docs(SRV): update

---------

Co-authored-by: SamyOubouaziz <[email protected]>

Author: Bemilie

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.

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.

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.

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).
+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.