Danger of creating translation loop by misconfiguration

[BikeMike]

Hi Henk-jan,
It has happened a few times that bots-engine gets into a loop using
95-100% CPU, and I have had to kill the process. It took me a while to
figure out what was happening, but the cause was returning "alt"
values from the first mapping, with accidentally missing, incorrect or
disabled translations.

1. first translation with no alt value runs.
2. the first translation returns an alt value to do a chained
translation (eg. a cutomised order response file).
3. no matching active translation is found with this alt value
(configuration error)
4. therefore the translation with no alt value is chosen and runs
again - result is an infinite loop.

The logic in transform.py (line 164) is to consider translations that
match the alt value, but also match translations with no alt value. I
understand this logic for the partners, but for alt I think the rule
should be that it "must match" otherwise raise
TranslationNotFoundError.

For me the easiest fix is change line 164
AND (alt='' OR alt=%(alt)s)
to
AND alt=%(alt)s

I guess there may be situations that would rely on the logic the way
it is now but I cannot envisage any. Can you see a need for it to
remain as-is? The other alternative may be to add a setting in
bots.ini for this. eg. altTranslationsMustMatch=True and default it to
False so existing behaviour is not affected.

Kind regards,
Mike

[BikeMike]

I have implemented this in transform.py with a parameter in bots.ini so
that it's backwards compatible.

[settings]
.
.
#if True: translation must exist that matches alt value (help prevent
accidental loops) Default: False means blanks also match
alttranslationsmustmatch=True

Kind Regards,
Mike

[hjeb...@gmail.com]

hi MIke,

use cases for alt:
- chained translation (as you describe)
- alt value can be given in eg route;

BikeMike wrote:
> Hi Henk-jan,
> It has happened a few times that bots-engine gets into a loop using
> 95-100% CPU, and I have had to kill the process. It took me a while to
> figure out what was happening, but the cause was returning "alt"
> values from the first mapping, with accidentally missing, incorrect or
> disabled translations.
>

yes, ran into that couple of times. quite annoying.

> 1. first translation with no alt value runs.
> 2. the first translation returns an alt value to do a chained
> translation (eg. a cutomised order response file).
> 3. no matching active translation is found with this alt value
> (configuration error)
> 4. therefore the translation with no alt value is chosen and runs
> again - result is an infinite loop.
>
> The logic in transform.py (line 164) is to consider translations that
> match the alt value, but also match translations with no alt value. I
> understand this logic for the partners, but for alt I think the rule
> should be that it "must match" otherwise raise
> TranslationNotFoundError.
>

I agree.

> For me the easiest fix is change line 164
> AND (alt='' OR alt=%(alt)s)
> to
> AND alt=%(alt)s
>
> I guess there may be situations that would rely on the logic the way
> it is now but I cannot envisage any. Can you see a need for it to
> remain as-is? The other alternative may be to add a setting in
> bots.ini for this. eg. altTranslationsMustMatch=True and default it to
> False so existing behaviour is not affected.
>

I can not think of such situations.
I know that I struggled here with default values during deveopment of
bots 1.*:
what is the default value of alt in the translate table, what is the
value of alt in ta.
probably this was the best solution at that time.

the solution you suggest is better now.

henk-jan

> Kind regards,
> Mike
>
>
>

[henk-jan ebbers]

hi mike,

fixed this in the development version.

henk-jan

[BikeMike]

Hi henk-jan,
Thanks, I agree it is better to just remove the fall back to blank alt
values. As long as it is mentioned in release notes it should not
cause a problem for anyone.

Kind Regards,
Mike

[hjebbers]

hi Mike,

I am looking again at this:
when the alt translation is not found the translation without the alt is used.

I once did this, you proposed to remove it because b(in case of misconfiguration) this gave an annoying loop in translation.
I could not remember the use case why I implemetned it liek that.
I do know the use case now:
 - get alt via QUERIES
-  alt has a lot of values, but only for one this leads to alt translation, for others the default translation is used.

Disadvantage would be that loops can occur again, which would be not very nice.
So I am trying to find another way to prevent this.
any ideas?

kind regards,
henk-jan

[BikeMike]

Hi Henk-jan,
How about if you configure an alt value of * (asterisk) it means match anything else?

In this way you are explicitly telling bots to match "unknown" values and accept the risk of creating a loop. Leaving alt blank will still only match no alt as it does now.

Kind Regards,
Mike

[henk-jan ebbers]

hi Mike,

looked at this.
this looked like best solution:
in translation, look if the alt value produced by the mapping script is the same as previous one.
if it is, and this happens more than 10 times, give an error.

I did setup a translation where the same alt was used over and over agina, but this is best considered an exception.
will implement this as a special case, where the alkt value is a dict, and a special 'type' for this (in oterh words, if user want this, disable the infinite loop dectection)

this this would solve the issue?

kind regards,
henk-jan

> --
> You received this message because you are subscribed to the Google Groups "Bots Open Source EDI Translator" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to botsmail+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[BikeMike]

That sounds like a good solution.