Result Delegate never called to Load table in DynamoDB in Unity3D (C#)

Question

• Unity Version : 2017.3.1f1
• AWS Service : DynamoDB
• Testing Environment : Mac OSX on the editor

Scenario

Trying to load a table from Dynamo DB but having weird issues.

It loads extremely well when I use the primary HASH key that is valid but when I supply a wrong HASH key (key that is not present in the database), the delegate is never called.

Source

private void performLoadOperation()
{
    ExperienceListing _experienceListing = null;
    string _ISEN = "21-89297083-ebe3-40b2-a269-3cfe80922fed";

    DH.log ("About to load ");
    Context.LoadAsync<ExperienceListing>
    (_ISEN, (_result)=>
        { 
            Debug.Log ("result returned - " + _result.Result.Title);
            if(_result.Exception == null)
            {
                _experienceListing = _result.Result as ExperienceListing;
                Debug.Log ("Title - " + _result.Result.Title);
            }
            else
            {
                Debug.Log ("Exception - " + _result.Exception);
            }
        }
    );
}


[DynamoDBTable("ExperienceListing")]
public class ExperienceListing
{
    [DynamoDBHashKey]   // Hash key.
    public string ISEN{ get; set; }
    [DynamoDBProperty]
    public string Title{ get; set; }
    [DynamoDBProperty]
    public string Blurb{get;set;}
    [DynamoDBProperty]
    public int Views{ get; set; }
    [DynamoDBProperty]  
    public int Rating{ get; set; }
}

Test Case

For the above performLoadOperation(), the delegate is being called properly. Now let's say that I change _ISEN variable to a string that is not present in the database, the delegate never gets called. I would like to note that, the internet is available.

Request

1. Am I supposed to give the correct hash key at all times and should understand that the delegate would never be called for invalid/wrong hash key's?

---

EDIT

The following worked for me but still it is wierd.

private void performLoadOperation()
{
    ExperienceListing _experienceListing = null;
    string _ISEN = "08c0ba69-af71-4017-afb8-5040f7033b33";

    DH.log ("About to load ");
    Context.LoadAsync<ExperienceListing>
    (_ISEN, (_result)=>
        { 

            if(_result.Exception == null)
            {
                _experienceListing = _result.Result as ExperienceListing;
                Debug.Log ("No Exception");
                if(_experienceListing == null)
                {
                    Debug.Log ("Experience Listing is null");
                }
                else
                {
                    Debug.Log ("Experience Listing not null - " + _experienceListing.Title);
                }
            }
            else
            {
                Debug.Log ("Exception - " + _result.Exception.Message);
            }
            if(_result == null)
            {
                Debug.Log ("Return result is null");
            }
        }, null
    );
}

When none of the "_result" is access for print logs, the logs were printed. As from advice from @MikeDinescu , tested with breakpoints which gave indication that delegate was called.

With the above solution, when the _result is still not null - it is required to manually check _experienceListing to know whether DyanomoDB has any of the tables from the hash key.

Answer 1

The delegate should be called regardless of whether the operation retrieves a result or not. In the case when there is no item matching the key, Result would be null and Exception would contain the error details.

However, the callback lambda contains a null reference exception right on the first line. Most likely what is happening is the lambda is invoked but throws an exception right away because it’s trying to dereference the Null result.

Are you sure it isn’t called? Have you tried putting a break point on the first line of the lambda?

The other thing to try would be to change the first Debug.WriteLine in the callback lambda to be a simple string, removing the part that attempts to dereference _result.Result, and then check if the debug message is printed even when the result is an exception.