Sync error status not update, Better sync message architecture should implement

[Resanehlab]

Hi,

I'm trying to develop an integration to HubSpot for an E-commerce platform. I use E-commerce bridge endpoints to sync the data to HubSpot. I have a problem and also a suggestion for this feature. The problem is when I use https://api.hubapi.com/extensions/ecomm/v2/sync/errors?showResolvedErrors=true endpoint to get all the sync errors (with OAuth), the error status for all the errors is always "OPEN" and never changes to "RESOLVED". I checked the error for the specific externalObjectId and, it didn't change when a successful sync message was applied to that. I can't figure out why the status doesn't change?.

Besides all that mentioned, I think the current architecture and pattern for sync messages is not the best one, and it forces developers to make multiple and redundant calls to check the sync errors. I wrote an integration for MailChimp API before and, I think they have a very convenient and reasonable approach for their sync messages. When you post a batch of sync requests to MailChimp, the API sends the response to a webhook URL which you've defined before. That response contains all the succeeded and failed sync messages along with errors and, you can check the status of all the sync messages that you've sent. This will prevent you from making error checking calls. I think that way provides a better solution for us to achieve data integrity. In the end, it would be so nice to share your thought with me about this.

Thanks for your support in advance.

[Derek_Gervais]

Hey @Resanehlab ,

Thank you for the feedback; I've passed that along internally to my team. I don't think I've seen that design pattern before (e.g. async call with response sent to webhook URL), and it's always interesting to get suggestions like this. If you haven't already, I'd also encourage you to post this as an idea on the HubSpot Ideas Forum, since that's where the team aggregates feedback.

Regarding your question; my understanding is that the error messages should update to `RESOLVED` when they've been resolved. Can you send me your appId so that I can investigate further?

[Resanehlab]

Sorry for the delay! We were on vacation, that's why I wasn't at my workplace.

Sure. I will submit a post about this on Ideas Forum. It will be my pleasure to help your team.

Regarding my problem, our AppId is 196352.

[Derek_Gervais]

Hey @Resanehlab ,

Thank you! I'm digging into this with the team now; I'll update this thread when I have more information.

[Resanehlab]

Any update on this?

[Derek_Gervais]

Hey @Resanehlab ,

So this is actually an issue with the way the Ecommerce Bridge API marks sync errors as resolved. Without getting into too many specifics, sync errors cannot currently be marked 'RESOLVED' because of an issue with a backend service. For the time being, you can confirm that a sync error has been resolved by checking the sync status of a given object.

[himanshurauthan]

Hello @Derek_Gervais 

Yes you are right. To be sure on the sync message, we can check sync status for an object and that returns the accurate data.
It can be the case that someone can get 40X on status check for the first call immediately after running the sync message API but checking the sync status for 3-4 attempts makes everything work better.

As the sync can only be considered as a success, when we get 20X status on a sync status for a object.

Thanks.

[Resanehlab]

Thanks for your response, but when we can expect to use this feature without the issue?

[Derek_Gervais]

Hey @Resanehlab ,

I don't have any definitive timelines here yet, but this is already on the team's radar. It's not a quick fix, but I'll be sure to keep this post updated with any new information.

[Derek_Gervais]

Hey @Resanehlab ,

Not just yet; sorry for the radio silence here. The team is still digging into this; I'll reach back out to them and see if we can get an update this week.