eCommerce Bridge not accurate to see if the error is relevant to the latest update

SOLVE
Highlighted
New Contributor

Hi

 

This is just to report a design/document problem I find. Not sure if this is right place.

 

In the eCommerce Bridge doc "Check the sync status of an object" says "You can check if the error is relevant to the latest update by comparing the erroredAt to the lastProcessedAt field" but consider the following data

 

The first action failed, the returned status is

{
    "storeId": "eb-test-wenbo",
    "objectType": "CONTACT",
    "externalObjectId": "1234-5678",
    "hubspotId": null,
    "lastProcessedAt": 1566277206248,
    "errors": [
        {
            "portalId": 5892170,
            "storeId": "eb-test-wenbo",
            "objectType": "CONTACT",
            "externalObjectId": "1234-5678",
            "changedAt": 1566276940501,
            "erroredAt": 1566277205975,
            "type": "MISSING_REQUIRED_PROPERTY",
            "details": "Message missing required fields [email]",
            "status": "OPEN"
        }
    ]
}

erroredAt < lastProcessedAt, difference is 273 ms

 

The second action succeeded, the returned status is

{
    "storeId": "eb-test-wenbo",
    "objectType": "CONTACT",
    "externalObjectId": "1234-5678",
    "hubspotId": 213651,
    "lastProcessedAt": 1566277635095,
    "errors": [
        {
            "portalId": 5892170,
            "storeId": "eb-test-wenbo",
            "objectType": "CONTACT",
            "externalObjectId": "1234-5678",
            "changedAt": 1566276940501,
            "erroredAt": 1566277205975,
            "type": "MISSING_REQUIRED_PROPERTY",
            "details": "Message missing required fields [email]",
            "status": "OPEN"
        }
    ]
}

The error remains as same as the first status, this is mentioned in doc.

The problem is, erroredAt < lastProcessedAt, same as when it's error.

 

For this very case, there is no problem because what I'm checking is field `hubspotId` to be not null.

 

In general, it also should not be a big problem because when the error is for the current update, the difference lastProcessedAt - erroredAt should be very small (< 1000ms I guess), and when the error is from a previous update, the difference should be very large, depending on business logic (when and how to retry and fix the error).

 

However, it would be nice to let erroredAt = lastProcessedAt or put the `changedAt` of the current action in returned status so that when the error is for current update, so we have a definitive indication, either `erroredAt == lastProcessedAt` for the former or `error.erroredAt > status.changedAt` for the later.

 

 

Cheers

 

Wenbo

 

Reply
0 Upvotes
1 Accepted solution

Accepted Solutions
Highlighted
New Contributor

Just to add that one way to find the error for recent update is to compare `changedAt` field.

It seems error.changedAt is copied from the input message, so after an update is sent, it should be true `error.changedAt == message.changedAt` otherwise the error must be from an old update.

 

2 Replies 2
Highlighted
HubSpot Moderator

Welcome, @wenbo.

 

This is valuable feedback — thank you for sharing!

 

I'll be sure the relevant stakeholders are aware.

Isaac Takushi

HubSpot Developer Support
Reply
0 Upvotes
Highlighted
New Contributor

Just to add that one way to find the error for recent update is to compare `changedAt` field.

It seems error.changedAt is copied from the input message, so after an update is sent, it should be true `error.changedAt == message.changedAt` otherwise the error must be from an old update.