createdAt missing in dynamodb item entry

I have a dynamodb table that I declared using dynamoose as below:

const schema = new dynamoose.Schema({
    "email": String,
    "name": String,
    "vehicleMotor": {
        "type": Number,
        "default": 0
    },
    "vehicleMotorId": String,
    "vehicleMotorImage1File": String,
    "vehicleMotorImage2File": String,
}, {
    "saveUnknown": true,
    "timestamps": true
});

From my understanding, when I have "timestamps": true declared, it should have both createdAt and updatedAt field.

So when I run my code that looks like this

if (new){
    const newSeller = new Seller({
        "email": email,
        "name": name
    })
    var saveResult = await newSeller.save();
}else{
    var updateResult = await Seller.update( { "email": email, sellerType: 1 }, {
        "name": name
    })
}

and when I checked the inserted/updated data inside Amazon DynamoDB Management Console, there's no createdAt, only updatedAt. By right I should also have createdAt too right? If not, how to make sure createdAt will always be there?

Based on the comment from the original poster. It looks like this is only occurring for the update call.

There isn't quite enough information in the original question for me to give a concrete answer as to what I believe is the best solution. So I'm going to make a few assumptions, and give a lot of high level detail about how Dynamoose handles this situation.

Just a little bit of the behind the scenes which will help make my answer more clear. From Dynamoose's perspective, it has no idea if the document/item already exists in the database or not. That leads to a situation where createdAt is difficult to get 100% accurate. You are running into one of these situations. For the update call, Dynamoose assumes that the document already exists, and therefore doesn't set the createdAt timestamp. This makes sense because createdAt doesn't really match with an update call. However, DynamoDB & Dynamoose technically allows for using update to create a new document/item. But Dynamoose has no way of knowing which it is, so we use the behavior of assuming update means not creating a new document for this context.

As for a possible solution. You have a new variable. I'm curious how you are defining that variable. One option would be to check the table using a get call and see if the document already exists. If you do that as your new variable, it should work fine. Because it will save if it doesn't exist, and if it already exists, it should have the createdAt variable already. Major downside to this is that you have to always do a read operation before writing. Which increases the latency of the application, and slows things down. But it will achieve what you want.

Now. In the event you have documents in your table that don't have the createdAt timestamp (ex. you created it outside of Dynamoose, or you created it before adding the timestamp option), the above solution won't work. This is because even checking to see if it exists, will cause the update method to be run, which Dynamoose assumes to be an update not a creation. In this case, any solution is really dependent on what your application wants to do. The item already exists in the table, so it's impossible to know when the true createdAt timestamp was (unless you keep logs and all that). You could run a one time operation to go through and add the current timestamp to the createdAt field if it doesn't have it for each document (but again that won't be truly accurate). Or of course you could just ignore it, and not rely on that field always.

To summarize, the timestamps feature in Dynamoose is truly a client side feature. Dynamoose has limited insight into the state of the data, and DynamoDB doesn't provide this functionality built in. This means Dynamoose has to make assumptions about how to handle these situations. However, if you follow Dynamoose's patterns for timestamps (ex. update won't add the timestamp and should only be used for updating existing items, creating all items in Dynamoose, etc), it will be totally accurate, and you won't run into any of these pitfalls.

If you have any creative solutions for how to improve Dynamoose's knowledge here, feel free to create a pull request on the repo or create an issue to discuss your ideas.