Pull and push: mapping object is currently pulling, so we do not push it

[amp42]

Goal In SF capture the date/time when the corresponding WP record was created by this plugin in WP

Describe the bug WP to SF push fails when the record is created in WP via a pull from SF by this plugin

To Reproduce

1. WP: create a custom post type contact. WP Contact is shorthand (name) for the entity that is the post with this custom type.
   • Field: record_id
2. SF > Contact object: Create a custom DateTime field, call it Created in WP
3. Map SF Contact to to WP Contact

• Pull from SF based on SystemModStamp

• WP Field: record_id : SF Field: Id

  • Prematch: yes
  • Salesforce key: yes
  • Direction: SF to WP

• WP Field: post_date: SF Field: Created in WP

  • Direction: WP to SF

• Action Triggers

  • WP Create
  • SF Create
  • SF Update
  • SF Delete

• Process Asynchronously: selected

Expected behavior When a Contact record is created in SF, it's created in WP via pull by the plugin. This works. When the WP Contact is created, push the post_date over to SF using the record ID to upsert the field.

Observed behavior The log in debug mode has the following three statements with roughly the same timestamp:

1. Debug: Start to add Salesforce ID <...> to the queue
2. Debug: Salesforce ID <...> has been successfully pulled into the queue.
3. Debug: mapping object transient ID <...> is currently pulling, so we do not push it

Environment (please complete the following information):

• WordPress Version: 6.1.1
• ObjectSync: 2.2.4
• PHP Version [e.g. 7.1]

Additional context If I remove the pull operation from happening at the same time on the same record, the push works. It's only when pull is creating the record in WP and push back to SF is triggered at roughly the same time, the push doesn't work.

[jonathanstegall]

This is not a bug, this is expected behavior for this plugin. Without this behavior, the plugin would essentially fall into an infinite loop of updating.

There might be other ways of getting around this problem than the once we chose in building the plugin – and if you have one of those, feel free to submit a pull request – but certainly the way it works is the way we intended it to work.

[amp42]

Jonathan -

I agree that under some conditions it can be infinite loop. In my case, I didn't think the loop is an issue since I am not triggering on WP Update. I thought this would happen:

1. A record is created in SF. On create in SF trigger fires.
2. The record is sent to WP and created there. On create in WP trigger fires
3. The record is upserted in SF. Since it already exists, upsert is an update. On update trigger in SF fires
4. The record is updated in WP. There's no on update in WP trigger, the sequence stops here.

[jonathanstegall]

Sure. Well, the part where you say "The record is updated in WP. There's no on update in WP trigger, the sequence stops here" is unfortunately not how WordPress works. That event would trigger an update event, which would then trigger an update in Salesforce and on and on.

I do realize that if the plugin didn't ever have an "update" trigger for WordPress events, maybe it could be built the way you describe, but it does depend on being able to detect update events and sync them.

[amp42]

I do realize that if the plugin didn't ever have an "update" trigger for WordPress events, maybe it could be built the way you >describe, but it does depend on being able to detect update events and sync them.

In my case, I don't have WP Update trigger selected in the fieldmap. This is why I didn't expect the plugin to consider this an infinite loop possibility and prevent the WP -> SF sync via WP Create trigger.

[jonathanstegall]

That's fair. I could see a scenario where the plugin acts differently for configurations where WP Update is not a selected trigger. It's not a bug though; this would be a significant new feature. I don't think it's a bad feature necessarily, as long as it doesn't interrupt the default behavior where any trigger could be selected. But the plugin doesn't currently have anyone actively working on it, so it's hard to imagine it being possible. I'll reopen it though, as a feature request.