"Result Processing" step is missing in workflow background task

Hello Experts,

We have an approval workflow which is abruptly stopping at a particular background step. This step has a very basic logic to get the next release code from custom tables based on the current release code and document type.

A few points of note are :-

• The background step status is showing as "completed"
• The next step in the workflow does not start
• There are no dumps in ST22 t-code
• There are no errors recorded in the step or workflow. Also nothing in the "extras->All Errors" popup

This does not happen always and when we did a comparison analysis of the correct and stopped workflows, we found the following :-

• If the user who approves logs-in with language DE, then the workflow stops at the background step (the approval dialog step is a few background steps before the "next release code" background step)
• If the user approves via EN, then the workflow runs correctly (imp: there is no language dependent code in the background step Image may be NSFW.
  Clik here to view. )
• The difference between the successfully executed and incorrect work items is
  • The step "Result Processing" is missing in the incorrect work item
• The result variable, which contains the next release code is filled correctly in the step container, but is not passed to the workflow container (We suspect this is because the step mentioned above did not execute)

Checks we have done:-

1. Checked the entire workflow for errors -> found none!
2. Checked the steps executed for binding errors -> found none!
3. Checked binding between workflow->task -> no errors!
4. No binding exists between task->business object method
5. Simulated the business object method by providing the parameters as in the real scenario -> correct output and no errors!
6. Searched SCN and internet for similar problems -> found only 1 discussion and the answer was binding issue

My question is,

• I suspect it to be a binding issue between the workflow and task containers. If so, how can I prove it (other than the obvious syntax check button in the binding window)?
• How is language playing the devil's role here? Are there generally problems if the workflow user and the approving user have different languages?
• Should SWUD already show the hidden problems of binding in the workflow? The results of SWUD on our workflow was clean.

If someone has an opinion on it, please share your view Image may be NSFW.
Clik here to view.