Regression 3.0.1 vs 2.15.3: client external Ingest

[fredericBregier]

Découpage en deux Issues sur les deux clients

Cette erreur n'arrive pas en 2.15.3, mais arrive en 3.0.1:

13:19:05.212 [IngestManager-1] WARN org.waarp.vitam.ingest.IngestManager - org.waarp.vitam.ingest.IngestManager.getStatusOfATR(IngestManager.java:542) : Issue since ingest client produces an error
fr.gouv.vitam.common.exception.VitamClientException: fr.gouv.vitam.ingest.external.api.exception.IngestExternalClientServerException
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.downloadObjectAsync(IngestExternalClientRest.java:128)
at org.waarp.vitam.ingest.IngestManager.getStatusOfATR(IngestManager.java:519)
at org.waarp.vitam.ingest.IngestManager.runStep(IngestManager.java:338)
at org.waarp.vitam.ingest.IngestManager.run(IngestManager.java:286)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: fr.gouv.vitam.ingest.external.api.exception.IngestExternalClientServerException: null
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.check(IngestExternalClientRest.java:188)
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.downloadObjectAsync(IngestExternalClientRest.java:125)
... 6 common frames omitted

Cause probable:

• 165aeb5#diff-ea6d6c4758da9bfec23550c434768e81
• d91f944#diff-ea6d6c4758da9bfec23550c434768e81

où le code async a été changé en profondeur...

Mon code s'inspire très fortement des tests Junit de Vitam pour le client Ingest External Rest et y intègre simplement un outil intermédiaire (waarp) qui fait appel au client Ingest External Rest.

En V2.15, aucun soucis (comme avant 2.11, ...). Mais en 3.0.1, le code Junit se plante dans le check du client external, sans que quoi que ce soit semble différent entre le code Junit v3.0 et V2.15 de Vitam sur ce point:

https://github.com/ProgrammeVitam/vitam/blob/master_3.0.x/sources/ingest/ingest-external/ingest-external-client/src/test/java/fr/gouv/vitam/ingest/external/client/IngestExternalClientRestTest.java

[fredericBregier]

Il n'y a aucun erreur de ce type avec 2.15... donc pas de log...

[TDevillechabrolle]

Merci pour avoir scindé les issues.
Nous avons essayer de reproduire le dysfonctionnement constaté, mais en l'état nous n'y parvenons pas. Nos propres tests junit ne connaissent pas de problème notamment.
Il nous manque probablement des éléments de contexte.
Serait-il par exemple possible de disposer du code junit qui plante sur la 3.0.1 pour essayer de reproduire l'issue ?

[fredericBregier]

OK, même constat que pour DIP (Access External Client): changement de comportement fonctionnel du client Java lors d'une erreur 500

En 2.15, le log produit:

 17:06:30.737 [IngestManager-1] ERROR org.waarp.vitam.ingest.IngestManager - org.waarp.vitam.ingest.IngestManager.getStatusOfATR(IngestManager.java:534) : Issue since ingest packet produces an error
Internal Server Error

En 3.0.1:

 17:05:19.208 [IngestManager-1] WARN org.waarp.vitam.ingest.IngestManager - org.waarp.vitam.ingest.IngestManager.getStatusOfATR(IngestManager.java:542) : Issue since ingest client produces an error
 fr.gouv.vitam.common.exception.VitamClientException: fr.gouv.vitam.ingest.external.api.exception.IngestExternalClientServerException
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.downloadObjectAsync(IngestExternalClientRest.java:128)
at org.waarp.vitam.ingest.IngestManager.getStatusOfATR(IngestManager.java:519)
at org.waarp.vitam.ingest.IngestManager.runStep(IngestManager.java:338)
at org.waarp.vitam.ingest.IngestManager.run(IngestManager.java:286)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
 Caused by: fr.gouv.vitam.ingest.external.api.exception.IngestExternalClientServerException: null
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.check(IngestExternalClientRest.java:188)
at fr.gouv.vitam.ingest.external.client.IngestExternalClientRest.downloadObjectAsync(IngestExternalClientRest.java:125)
... 6 common frames omitted

Donc même cause même effet: un changement du comportement du client produit une incompatibilité entre la version 2 et la version 3 pour un client de Vitam.

Je vais voir de mon côté pour rendre mon programme "tolérant" à cette incompatibilité ascendante (si je peux).

[fredericBregier]

Pour info, je rechigne à corriger mon code pour prendre en compte ce changement majeur car:

• en version 2.15: une exception VitamClientException n'était levée QUE si une erreur grave (IllegalStateException, VitamClientInternalException) mais pas pour un statut 500
• en version 3.0: une exception est systématiquement levée si non (SUCCESSFUL.equals(status.getFamily()) || REDIRECTION.equals(status.getFamily()))

Changement important, n'est-il pas ? 404 est aussi du coup une erreur Exception, et ainsi de suite...

Changer un retour normal par une exception qui, de plus, est déjà utilisée pour d'autres cas d'erreur, rend plus complexe la gestion des erreurs pour un client externe (comment fait il la différence entre une erreur temporaire et une erreur définitive, une erreur du client interne et une erreur du serveur externe) ?

Que proposez-vous ?

[fredericBregier]

Note: pour le moment, le fix n'est que temporaire et ne sera sans doute pas "validé" comme merge, c'est plus pour vous montrer les impacts...

[TDevillechabrolle]

Bonjour Frédéric,
Le comportement de gestion des status par le client REST observé jusqu'ici n'était pas normal, et a été catégorisé comme un bug ( 6072 ).
Ce bug, comme vous l'avez constaté, a été corrigé dans la v3.0.1

[fredericBregier]

Certes, mais du coup, c'est un retour en arrière (contrat de fonctionnement).
De plus, il est alors impossible pour l'utilisateur du client de connaître la raison (4xx, 5xx, ...) ou de faire une distinction avec une erreur interne du client Vitam (et non de la réponse Serveur).

Du coup, il est impossible de prendre en compte des statuts différents de réponse du serveur et donc de traiter ces erreurs différemment. Ceci est un problème grave selon moi.