vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[No action matches built-in action](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/no-action-matches.png)

No action matches built-in action

By default, this action has two steps, each step conditioned on the No action matches count session variable. This is a built-in variable that is automatically incremented with each consecutive unrecognized input. Therefore, the behavior of the No action matches action differs depending on how many times in a row the user has said something the assistant didn't understand:



* For the first three unrecognized messages, step 1 executes. This step simply outputs a message saying that the assistant did not recognize the user's input, and asking the user to try again. You can edit this step to change the message, or modify the step condition to change how many times the assistant responds with this message.

When the user sends input that successfully triggers an action, the No action matches count session variable is reset to 0.
* If the user tries more than three times but the assistant still doesn't understand, step 2 executes. Step 2 calls the Fallback action, which offers other options like connecting to a live agent. For more information about the Fallback action, see [Editing the fallback action](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-handle-errorsfallback-action).



You can edit the No action matches action just as you can any other action. This includes changing the existing steps and adding or deleting steps. Note that if you change the No action matches action, you might accidentally break your assistant's ability to recover from errors in the conversation. If this happens, you can recreate the default steps based on the information in this section.



 Adding examples of unsupported input 

By default, the No action matches action is triggered only when the user's input does not match any defined action.
curl -X PUT "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/config/tokens" -H 'Content-Type: application/json' -H "Authorization: Bearer <IAMToken>" -d '{
"access": {
"expires_in": 3600
},
"refresh": {
"enabled": true,
"expires_in": 2592001
},
"anonymousAccess": {
"enabled": false
},
"accessTokenClaims": [
{
"source": "roles"
},
{
"source": "saml",
"sourceClaim": "name_id",
"destinationClaim": "id"
}
],
"idTokenClaims": [
{
"source": "saml",
"sourceClaim": "attributes.uid"
}
]
}'
Show more



Table 3. Understanding the token configuration

 Variable Description 

 access: expires_in The length of time for which access tokens are valid. The smaller the value, the more protection that you have in cases of token theft. The value is provided in seconds and can be any whole number in range 300 and 86400. The default value is 3600. 
 refresh: expires_in The length of time for which refresh tokens are valid. The smaller the value, the more protection that you have in cases of token theft. The value is provided in seconds and can be any whole number in range 86400 and 7776000. The default value is 2592000 (30 days). 
 anonymousAccess The length of time for which an anonymous token is valid. Anonymous tokens are assigned to users the moment they begin interacting with your app. When a user signs in, the information in the anonymous token is then transferred to the token associated with the user.
* A request would use an existing resource (for example, to generate a new resource) which has client-mutable state preventing such use.
* A request would delete a resource that another resource depends on.



The following scenarios MUST NOT result in a 409 Conflict:



* A request has an internal conflict. This SHOULD result in a 400 Bad Request.
* A request depends on a resource that does not exist. This SHOULD result in a 400 Bad Request.
* A request would update or create a resource with a binding to an existing resource that the user is unauthorized to bind to. This SHOULD result in a 403 Forbidden unless the user is [not permitted to know about](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-status-codesinformation-exposure-with-401-and-403) the existing resource.
* A request would conflict with state that is invisible to clients. This MUST NOT happen by design, but unexpected runtime scenarios MAY result in a 500 Internal Server Error.
* A request would conflict with state that is immutable for clients. This SHOULD result in a 400 Bad Request.
* A safe[10] request cannot be made because of the current state of the system. This SHOULD NOT happen by design. Consider modeling the missing functionality as an "empty" resource with a 200 OK response or an absent resource with a 404 Not Found response.



The following scenarios SHOULD NOT result in a 409 Conflict:



* A request cannot be processed because of transient resource state and the client is advised to wait for that state to change and retry the request. This SHOULD NOT happen by design, but if it does, it MAY result in a 409 Conflict.
* A request would update or create a resource with a binding to an existing resource which has irrecoverably failed or expired. This SHOULD result in a 400 Bad Request.
* A request would use an existing resource (for example, to generate a new resource) which has irrecoverably failed or expired. This SHOULD result in a 400 Bad Request.









 Server errors: 5xx 



Server error status codes

 Code Meaning Description
The regular live migration process is nondisruptive and use of dedicated hosts and virtual servers is not interrupted.

When nondisruptive live migration occurs, the virtual server experiences a brief pause of around 10 seconds, and in some cases up to 30 seconds. You are not notified in advance of nondisruptive migration. The virtual server instance is not restarted as part of this process.

In cases where a disruptive migration is required, you are notified 30 days in advance of the scheduled migration. The virtual server instance is restarted as part of this process.

In limited cases, a virtual server restart might be required to complete the host or data center maintenance. This scenario can occur when specialized VMs are used or if the virtual server encounters a migration problem. In this case, a scheduled maintenance event occurs.

For more information about unscheduled migrations that result from an unexpected host failure, see [Host failure recovery policies](https://cloud.ibm.com/docs/vpc?topic=vpc-host-failure-recovery-policies&interface=cli).





 What to expect during a scheduled maintenance event 

In scenarios where workloads cannot migrate automatically, a scheduled maintenance event occurs. When workloads can't migrate automatically, the account owner receives an email about the upcoming maintenance that requires their attention. The account owner has a maintenance period typically 30 days in length. Exceptional cases can necessitate different timelines as outlined in [Getting advanced notice for disruptive maintenance](https://cloud.ibm.com/docs/get-support?topic=get-support-viewing-notificationsdisruptive-maintenance).

To start the maintenance event, the account owner needs to power-off their virtual server and then power it back on. This power cycle can be initiated as soon as a maintenance notification is received. When the virtual server resumes, it starts on the updated infrastructure. By doing so, the customer can choose when to perform the maintenance anytime ahead of the scheduled window.

If the account owner takes no action before the maintenance window, the server restarts during the window that is specified in the notification email.

When the virtual server is started, customer data and configurations are restored.
Because you likely still have admin certificates in the MSP that will expire, you still need to follow the manual steps in this topic to update them. But after you complete that process, you do not have to follow the manual steps again next year after the certificates expire, since you have now enabled the Node OU support on the MSP.







 Certificate renewal and expiration 

By default, most certificates that are generated by IBM Blockchain Platform CAs expire after one year. However, the CA root certificate, CA TLS certificate, and the ordering node TLS certificates have longer periods before expiration. The default expiration period is the same for certificates that are generated by using the Fabric SDKs, the Fabric CA client, or by using the console. The expiration date for all certificates that expire within five years is visible in the console, and how to view the actual date is described later in this topic.



 Automatic certificate renewal 

Use the following topics to set up automatic certificate renewal.



 Enrollment and TLS certificates 

Because the console automatically enrolls identities for peer or ordering nodes when the nodes are deployed, the IBM Blockchain Platform automatically renews the enrollment (signing) certificates for the peer and ordering nodes and the peer TLS certificate. If the certificates expire within 30 days, the platform automatically attempts to contact the CA and renew the certificates. After these certificates are automatically renewed, there is no further action that needs to be taken.

If the CA is offline, unreachable, or the CA TLS certificate has expired, the certificates cannot be automatically renewed. The peer or ordering node displays a warning message indicating that certificate expiration is approaching or has occurred and you need to take action.

Peer and ordering node enrollment certificates can be renewed from the console, by opening the node tile and clicking the Settings icon. Click Update certificates to renew either the enrollment or TLS certificate.
.
4. If you want to customize what happens next if the condition is met, then click the Edit response![Edit response](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/edit-slot.png) icon.

For Found responses (that are displayed when the user provides a value that matches the value type specified in the Check for field), you can choose one of these actions to perform next:



* Move on (Default): Instructs your assistant to move on to the next empty slot after displaying the response. In the associated response, assure the user that their input was understood. For example, Ok. You want to schedule it for $date.
* Clear slot and prompt again: If you are using an entity in the Check for field that could pick up the wrong value, add conditions that catch any likely misinterpretations, and use this action to clear the current slot value and prompt for the correct value.
* Skip to response: If, when the condition you define is met, you no longer need to fill any of the remaining slots in this node, choose this action to skip the remaining slots and go directly to the node-level response next. For example, you could add a condition that checks whether the user's age is under 16. If so, you might skip the remaining slots which ask questions about the user's driving record.



For Not found responses (that are displayed when the user does not provide a valid value), you can choose one of these actions to perform:



* Wait for user input (Default): Pauses the conversation and your assistant waits for the user to respond. In the simplest case, the text you specify here can more explicitly state the type of information you need the user to provide. If you use this action with a conditional response, be sure to word the conditional response such that you clearly state what was wrong with the user's answer and what you expect them to provide instead.
* Prompt again: After displaying the Not found response, your assistant repeats the slot prompt again and waits for the user to respond.
"aliveExpirationTimeout": "25s",
"reconnectInterval": "25s",
"election": {
"startupGracePeriod": "15s",
"membershipSampleInterval": "1s",
"leaderAliveThreshold": "10s",
"leaderElectionDuration": "5s"
},
"pvtData": {
"pullRetryThreshold": "60s",
"transientstoreMaxBlockRetention": 1000,
"pushAckTimeout": "3s",
"btlPullMargin": 10,
"reconcileBatchSize": 10,
"reconcileSleepInterval": "1m",
"reconciliationEnabled": true,
"skipPullingInvalidTransactionsDuringCommit": false
},
"state": {
"enabled": true,
"checkInterval": "10s",
"responseTimeout": "3s",
"batchSize": 10,
"blockBufferSize": 100,
"maxRetries": 3
}
},
"authentication": {
"timewindow": "15m"
},
"client": {
"connTimeout": "3s"
},
"deliveryclient": {
"reconnectTotalTimeThreshold": "3600s",
"connTimeout": "3s",
"reConnectBackoffThreshold": "3600s",
"addressOverrides": null
},
"adminService": null,
"validatorPoolSize": null,
"discovery": {
"enabled": true,
"authCacheEnabled": true,
"authCacheMaxSize": 1000,
When batching, jobs are not guaranteed to run in the order they are submitted.

Zoom

![Batch session execution diagram.](https://cloud.ibm.com/docs-content/v1/content/5f399fa794584e8a662591b494b9a99aa927c74c/quantum-computing/images/batch.png)

Figure 3. Batch session execution







 How long a session stays active 

The length of time a session is active is controlled by the maximum session timeoutmax_time value and the interactive timeout value (TTL). The max_time timer starts when the session becomes active. That is, when the first job runs, not when it is queued. It does not stop if a session becomes inactive. The TTL timer starts each time a session job finishes.





 Maximum session timeout 

When a session is started, it is assigned a maximum session timeout value. You can set this value by using the max_time parameter, which can be greater than the program's max_execution_time. For instructions, see [Run a primitive in a session](https://qiskit.org/documentation/partners/qiskit_ibm_runtime/how_to/run_session.html).

If you do not specify a timeout value, it is the smaller of these values:



* The system limit
* The max_execution_time defined by the program



See [What is the maximum execution time for a Qiskit Runtime job?](https://qiskit.org/documentation/partners/qiskit_ibm_runtime/faqs/max_execution_time.html) to determine the system limit and the max_execution_time for primitive programs.





 Interactive timeout value 

Every session has an interactive timeout value (TTL) of five minutes, which cannot be changed. If there are no session jobs queued within the TTL window, the session is temporarily deactivated and normal job selection resumes. A deactivated session can be resumed if it has not reached its maximum timeout value.
* If there are no log entries for an hour, an archive file will not be written for that hour.
* In rare cases log lines can be duplicated in archive files. Duplicates can be determined by the log line ID.
* Automatic archiving is disabled for an instance when an the credentials that are used to archive data are invalid for over 24 hours.



The first time the archive process runs the number of days archived is dependent on the plan:



* The maximum number of days that data is archived includes logs for the past 30 days when the instance has a 30 day search plan.
* The maximum number of days that data is archived includes logs for the past 14 days when the instance has a 14 day search plan.
* The maximum number of days that data is archived includes logs for the past 7 days when the instance has a 7 day search plan.



For example, you have a service plan of 30 days. You configured the instance 10 days ago. You enable archiving on the 10th day. The archiving process generates multiple files. Each file includes logs for the period of time indicated as part of its name. If there is no data, the archive file for that period is empty.



 Archived file format 

The archive directory format looks like this:

year=<YYYY>/month=<MM>/day=<DD>/<accountID>.<YYYY>-<MM>-<DD>.<HHHH>.json.gz

Where

YYYY represents the year; MM represents the month; and DD represents the day.

<accountID> represents the logging account ID, that is, the ID that is shown in the [web UI URL](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-get_web_url).

HHHH represents hours in 24 format.



* The timestamp that is used to determine whether the log is included in an archive is the UTC timestamp.



Depending on your location, there might be logs that you see in local time in your views on a specific day. However, you cannot find them in the archive file.
To protect your privacy, do not store your personal data as metadata for your key. 
 expiration_date Optional.The date and time that the key expires in the system, in RFC 3339 format (YYYY-MM-DD HH:MM:SS.SS, for example 2019-10-12T07:20:50.52Z). The key will transition to the deactivated state within one hour past the key's expiration date. If the expirationDate attribute is omitted, the key does not expire. 
 key_type Optional.A boolean value that determines whether the key material can leave the service. When you set the extractable attribute to true, the service creates a standard key that you can store in your apps or services. 



To protect the confidentiality of your personal data, avoid entering personally identifiable information (PII), such as your name or location, when you add keys to the service.

A successful POST api/v2/keys response returns the ID value for your key, along with other metadata. The ID is a unique identifier that is assigned to your key and is used for subsequent calls to the Key Protect API.

Optional: Verify that the key was created by running the following call to get the keys in your Key Protect service instance.

$ curl -X GET "https://<regon>.kms.cloud.ibm.com/api/v2/keys" -H "accept: application/vnd.ibm.collection+json" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>"





 What's next 



* To find out more about programmatically managing your keys, [check out the Key Protect API reference doc](https://cloud.ibm.com/apidocs/key-protect).
<br> <br>If automatic renewal fails, see [Manual certificate renewal](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-ordering-node) Production outage <br> <br>Orderers can no longer work. [Manual certificate renewal](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-ordering-node) 
 Orderer TLS certificate (signcert) When TLS is enabled on a network, each node must register a user and enroll an identity with the TLS CA. This is the TLS certificate for the ordering node from that process and is required for the ordering node to start. Generated when the ordering node is deployed. 2.5.x: 15 years <br> <br>2.1.x: 1 year Open console ordering node and view TLS Cert Expiration field. [Automatic renewal](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-auto-renewal) is attempted 30 days before expiration. <br> <br>If automatic renewal fails, see [Manual certificate renewal](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-ordering-node) Production outage <br> <br>Ordering nodes are no longer allowed to participate in cluster. Quorum is lost, environment goes down. [Manual certificate renewal](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-enroll-tls-ordering-node) 







 Peer admin certificate 

The following diagram summarizes the process for updating peer admin certificates on your network. Click a circle to view the instructions.

![Peer admin certificate renewal process.]
Expiration date (Optional) Set the date and time when the key gets expired. After the expiration date, the key moves into the Deactivated state. For more information about key state, see [Monitoring the lifecycle of encryption keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-states). 
 Description (Optional) Add an extended description for your key. It needs to be two to 240 characters in length. 



6. When you finish filling out the key's details, click Import key to confirm.







 Importing standard keys with the API 

Import a standard key by making a POST call to the following endpoint:

https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys



1. [Retrieve your service and authentication credentials to work with keys in the service](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-kms-api).
2. Call the [Hyper Protect Crypto Services key management service API](https://cloud.ibm.com/apidocs/hs-crypto) with the following cURL command.

curl -X POST 
https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys 
-H 'authorization: Bearer <IAM_token>' 
-H 'bluemix-instance: <instance_ID>' 
-H 'content-type: application/vnd.ibm.kms.key+json' 
-H 'correlation-id: <correlation_ID>' 
-H 'prefer: <return_preference>' 
-d '{
"metadata": {
"collectionType": "application/vnd.ibm.kms.key+json",
"collectionTotal": 1
},
"resources": [
{
"type": "application/vnd.ibm.kms.key+json",
* The responseData.maxAllowedRetrievals field includes the maximum amount of times the import token can be retrieved within its expiration time before it is no longer accessible.
* The responseData.remainingRetrievals field includes the number of times the import token can be retrieved within its expiration time before it is no longer accessible.







 Completed action of a key rotation 

The following fields include extra information:



* The responseData.eventAckData.eventId field includes the unique identifier that is associated with the event.
* The responseData.eventAckData.eventType field includes the type of lifecycle action that is associated with the event.
* The responseData.eventAckData.newKeyVersionId field includes the unique identifier of the latest key version used to wrap input ciphertext on wrap requests.
* The responseData.eventAckData.newKeyVersionCreationDate field includes the date that the latest key version was created.
* The responseData.eventAckData.oldKeyVersionId field includes the unique identifier of the previous key version used to wrap input ciphertext on wrap requests.
* The responseData.eventAckData.oldKeyVersionCreationDate field includes the date that the previous key version was created.







 Completed action of key restoration 

The following fields include extra information:



* The responseData.eventAckData.eventId field includes the unique identifier that is associated with the event.
* The responseData.eventAckData.eventType field includes the type of lifecycle action that is associated with the event.
* The responseData.eventAckData.keyState field includes the integer that correlates to the state of the key associated with the event.
* The responseData.eventAckData.eventAckTimeStamp field includes the date and time that the event was acknowledged.







 Completed action of an enabled key 

The following fields include extra information:



* The responseData.eventAckData.eventId field includes the unique identifier that is associated with the event.
* The responseData.eventAckData.eventType field includes the type of lifecycle action that is associated with the event.