AWS omics documentation change
Summary
Restructured troubleshooting documentation with added sections for call caching issues and expanded troubleshooting guidance
Security assessment
Adds operational troubleshooting content about call caching behavior but does not address security vulnerabilities or introduce security features. Focuses on cache configuration validation and diagnostic checks.
Diff
diff --git a/omics/latest/dev/troubleshooting.md b/omics/latest/dev/troubleshooting.md index ae8323bf7..888b239e0 100644 --- a//omics/latest/dev/troubleshooting.md +++ b//omics/latest/dev/troubleshooting.md @@ -5 +5 @@ -WorkflowsData stores +Troubleshooting workflowsTroubleshooting call caching issuesTroubleshooting data stores @@ -11 +11,12 @@ The following topics can help you troubleshoot issues that you encounter when us -## Workflows +###### Topics + + * Troubleshooting workflows + + * Troubleshooting call caching issues + + * Troubleshooting data stores + + + + +## Troubleshooting workflows @@ -48 +59,38 @@ If there are issues with your code and the processes have not exited properly, y -## Data stores +## Troubleshooting call caching issues + +The following topics can help you troubleshoot issues that you encounter with call caching. + +###### Topics + + * Why isn’t my run saving to the cache? + + * Why isn’t a task using the cache entry? + + + + +### Why isn’t my run saving to the cache? + + 1. Verify that the run is configured to use a cache by checking the cacheId field in the GetRun API operation response. Using the CLI, run this command: `aws omics get-run —id <run_id>`. + + 2. If the run was successful, verify the cache behavior returned in the GetRun response is CACHE_ALWAYS. If the cache behavior is set to CACHE_ON_FAILURE, runs will only save to the cache when they fail. + + + + +### Why isn’t a task using the cache entry? + +In the `/aws/omics/WorkflowLog` CloudWatch log group, open the log stream for the run cache: **runCache/ <cache_id>/<cache_uuid>**. + + 1. Verify that a previous run created a cache entry for the task that you expected to be cached. Runs that have saved to the cache will be recorded with a log message of CACHE_ENTRY_CREATED. + + 2. Locate the CACHE_MISS log for the task and run that completed. If there is no log entry, check that the run was configured to use the cache. + + 3. If a cache entry was created, verify that the CPUs, memory, GPUs and container digest are identical for both tasks. The task ARN for the task that created the cache entry is in the log message. + + 4. If the compute requirements for both tasks match, verify that the inputs have not changed between the tasks. To do this, open the engine logs. If the run has a status of FAILED, the logs will be in Cloudwatch Log Group /aws/omics/WorkflowLog. Otherwise the engine logs can be found in the output directory of the run. + + + + +## Troubleshooting data stores