Wireless Diagnostic Assist

Please note: The download link will be sent to you via delivery email after you order.

Wireless Diagnostic Assist is used for Lambda debugging, which is not significantly different from any debugging process. You need to have a mental model of how the system and application work and look for the clues that narrow down the cause of the issues.

All of our labs, and the majority of new internet and in-house development is now using browser-based or API-based interconnects so I will discuss this in terms of an HTML browser environment. If you are doing something different, the elements will be similar but the tools may be different.

You need to have a mental model of how the stack works.

• You interact with a browser that runs HTML code to render (paint) the web page in your browser window.
• HTML can do a lot of things, however, more dynamic capability can be achieved by using the HTML to run Java scripts on your browser. This is called client-side scripting and is 100% compatible with S3 so it is a common add-on for Lambda environments. However it is not essential.
• The HTML code calls and paints objects that are either on your local system or downloaded. Each of these calls will result in a success or failure. These are reported by HTML status codes which can be seen in your browser 'Developer Tools / Console'.
• When you are working with Lambda the objects are provided either by a cloud object store (S3), or the API which sends an object or chunk of formatted HTML code back to your browser to make use of.
• While the API Gateway could send results back by itself, normally it will just proxy for back-end services. In this case, we are focussing on Lambda.
• Running code on Lambda is really just the same as running it on any other server. There are layers upon layers of handles and code and subroutines that are called and the execution is passed up and down these layers to complete the tasks at hand. Some of these layers are in the code you provide, and some are above it in the lambda handler, and some are below in the interpreter or underlying libraries such as C.

When Lambda or some other process is completed, the results are passed back up through each layer and service until your browser paints the results.

As you debug problems keep this hierarchy in mind and mentally place each log and error report you see where in the stack the issues are occurring.

Finding the problem.
There are lots of approaches to debugging.

1. The natural instinct is to just go look at things randomly to see if you have made a mistake. For a small project when you have some basic understanding of why the error occurred this can be effective. Did I add the comma, did I add the correct 'Environment Variable' etc. However it you cannot spot the error in 30 seconds, stop wasting time. and start looking systematically.

2. Trace the error hierarchically.
①Start at the top (at the browser) and follow the traffic down.

• Is there an error on the browser?
• Is there an unexpected failure in the 'Developer Tools / Console' HTML status codes.
• If something timed out what element does the 'Developer Tools / Network' indicate took too long?

Learning to use the Browser 'Developer Tools' to even a very basic level can shorten your debug time. And improve your confidence enormously :-).

②You can track activity through your API Gateway via CloudWatch. This is not enabled by default. Our labs are relatively simple and any problems are unlikely to be in the API, so only do this if you cannot resolve it elsewhere. If you are having a persistent problem then consider enabling logging for a while to see the traffic passing back and forth and any anomalies that may be present at the API.
Note: The logs can build up so remember to stop it or set up lifecycle management on your logging bucket to age the logs out.
③Lambda writes Logs automatically to CloudWatch and this is a great source of information, and where we will focus most of the following discussion.

3. Start with the most easily accessed Logs. In most cases, this will be the Lambda / CloudWatch logs. However, depending on the situation, there may be other material that you can review more easily.

A few guidelines I recommend:

• Use a separate browser for testing the application.
  (I find Opera and Safari are excellent for testing)
• Before each new test:

①Point your browser at a neutral page and Clear the Browser cache so that the objects from the last test do not contaminate the next test. (this is less impacting to your other activities if you use a separate browser)

②Clean out the CloudWatch Logs between tests. Delete old logs so that you start from scratch. This will make it easier to see which Lambda functions did and did not run, and reduce the lines you need to read through.

• Be clear in your mind about which Lambda function(s) should run for each activity. Run one test and check the CloudWatch logs to see which Lambda functions did and did not run.  Is something missing, is there something extra you did not expect. If things are not as you expected, check your understanding then look at how functions are being called and why it may or may not have run.
• Watch for typos and look-alike characters. 1lI o0O ,. Non-display special characters vs. space or tab.
• Check the Discussion Forums and see what others have experienced, and how they may have resolved it.  When you solve your issue don't forget to post advice for those who come after you, or up-vote useful posts.
• If in doubt, recreate the Resource or Lambda function that is problematic. It is good practice, and it gets faster each time you do it.  Learning from your mistakes can be very powerful, but you also need to manage the time you are investing in small errors.
• Use a proper code editor for typing and editing code. Don't use Word or Office tools, they have a bad habit of adding formatting and special characters that will mess things up. There are plenty of good quality free editors available.
• TextWrangler, Atom, PyCharms, SubLime, NotePad++, etc are some of the free and very good products available.

Reading the Lambda / CloudWatch logs. 
The Logs in CloudWatch may look intimidating when you 1st see them.  So many rows of cryptic information.  However, with a few simple steps, you can make it easier to understand.
If you followed the above guidelines you will have started with a clean environment and within 30 seconds of the function running you should have a set of logs available to review (you may need to refresh your AWS console to make them visible).
Below are some guidelines of what to look for to demystify the logs.

• You will note that the Log is in time sequence with the last action at the bottom and them getting progressively older as you move or scroll up the list.
• Each line represents an event.  For some, the body is a few words, others may be a large blob of test (see Hint below).   
• Each line starts with a keyword.  START, END, REPORT, or a status [INFO], [DEBUG], etc.
• Also note that START/ END/ REPORT is a set that describes an execution cycle.
• The REPORT record is a summary of the Lambda job.  Quickly check the time and memory used to see if it is what you expected. 
• The keywords [INFO], [DEBUG] etc are self-evident.  The [INFO] and [DEBUG] are generally only of interest in terms of what they inform you about [ERROR].  So start with the [ERROR] entries.
• Recall that the older entries are UP on the screen.  So when you find a fault read UP to see what precedes it, what was running, what parameters were passed, and were there any console messages in the logs showing what the developer was expecting to happen.
• If you add a 'print' or 'console' statement into your code it will be written in the log.  You can always add a 'print' or 'console' statement to the code as part of debugging to help you confirm each section of code is being processed.  The time taken to add these can significantly shorten the debugging time ;-)