Bug: Duplication in outbound push

[jonathanbataire]

Describe the bug
When configuring more than one out bound pushes without a cron configuration eg obp1 and obp2 the second configuration (obp2) will be pushed twice. Once immediately and another after about 5 mins

To Reproduce

• create out bound push with atleast 2 configurations to 2 target end points eg push-target1 and push-target2
• Configure both outbound pushes to be triggered by the same form type i.e relevant_to: doc.form === malaria_screening
• Leave the "cron" empty so pushes occur immediately as soon as the report is submitted
• Login as a user and submit the sample form (malaria_screening)
• Outbound push will push records to both push-target1 and push-target2 and create another task:outbound for push-target2
• After about 5 mins the push-target2 task will be executed and the same payload will be pushed to target2 again
  Expected behavior

• Target2 task shouldnt be created as it causes payload to be pushed twice

Logs

Screenshots

Environment

• Instance: dev instance on v4.9.0, local environment with v4.18.0
• Browser: Firefox and Chrome
• Client platform: Linux
• Version: 4.9.0 and the latest code 4.18.0

Additional context

[jonathanbataire]

@andrablaj can we back port the solution to 4.9 as this affects MoH-UG deployment

[andrablaj]

4.9 is not supported anymore, so backporting to 4.9 is not a recommended approach. The ideal would be to upgrade MoH Uganda to a more recent, supported version. Is the upgrade option viable for MoH Uganda?

[jonathanbataire]

4.9 is not supported anymore, so backporting to 4.9 is not a recommended approach. The ideal would be to upgrade MoH Uganda to a more recent, supported version. Is the upgrade option viable for MoH Uganda?

That's very unfortunate getting moh to upgrade especially a minor/major upgrade is very hard given the logistical aspect of it and the changes the upgrade will bring

[dianabarsan]

Hi @jonathanbataire
The advised path is to upgrade, but I understand it's very hard to get MOH signoff.

I think we should not do selective backports (for example release a 4.9.x with the fix, but not release a 4.10.x with the fix), and there are technical limitations to these backports - like fixes for "external" issues that you would need to identify and also cherry pick in order to get your build to pass (one example quickly comes to mind: 5d50e06 ) and I am sure this is not the only one.

Creating hotpatch branches with fixes is risky, because it further decreases the chances for future upgrades. We have done this very sparingly (maybe twice?) and never pushed more than one change, and it was always to fix absolutely critical bugs (and I don't believe this bug is critical).

How badly is the instance affected by this bug?
What is the logistical aspect of a potential upgrade that is preventing MOH approval?