Re: Propagation failure on update
- Le 16 Avr 24, à 8:39, Francesco Chicchiriccò ilgro...@apache.org a écrit : > On 11/04/24 10:30, Lionel SCHWARZ wrote: >> - Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schw...@in2p3.fr a écrit : >>> - Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgro...@apache.org a >>> écrit : >>> On 26/03/24 13:30, Lionel SCHWARZ wrote: > Dear all, > > After reading > https://syncope.apache.org/docs/reference-guide.html#propagation, > I ask myself a question: is there a way to avoid a User (or AnyObject) to > be > modified in case the propagation task fails? Hi Lionel, that's exactly the purpose of setting a non-null priority onto an External Resource: > the execution of a given set of tasks is halted (and global failure is > reported) > whenever the first sequential task fails would mean exactly that. >>> Thanks Francesco, I'll try this. >> Hi Francesco and all, >> >> After investigations and tests, I could indeed check that the sequence of >> tasks >> stops when the first task fails. >> But there is a remaining question: the attribute on the Entity itself (the >> USER), the one which triggered the propagation, keeps changed. So we are in >> the >> situation where the User has an attribute different than values in the remote >> repos. > > Yes, this happens by design: over time, we observed that refusing to upgrade > Syncope because of a propagation error, even on priority resource, was too > tight. Good to know, thanks for your answer Regards Lionel smime.p7s Description: S/MIME Cryptographic Signature
Re: Propagation failure on update
On 11/04/24 10:30, Lionel SCHWARZ wrote: - Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schw...@in2p3.fr a écrit : - Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgro...@apache.org a écrit : On 26/03/24 13:30, Lionel SCHWARZ wrote: Dear all, After reading https://syncope.apache.org/docs/reference-guide.html#propagation, I ask myself a question: is there a way to avoid a User (or AnyObject) to be modified in case the propagation task fails? Hi Lionel, that's exactly the purpose of setting a non-null priority onto an External Resource: the execution of a given set of tasks is halted (and global failure is reported) whenever the first sequential task fails would mean exactly that. Thanks Francesco, I'll try this. Hi Francesco and all, After investigations and tests, I could indeed check that the sequence of tasks stops when the first task fails. But there is a remaining question: the attribute on the Entity itself (the USER), the one which triggered the propagation, keeps changed. So we are in the situation where the User has an attribute different than values in the remote repos. Yes, this happens by design: over time, we observed that refusing to upgrade Syncope because of a propagation error, even on priority resource, was too tight. Is there a way to do kind of rollback on the USER update in this case? You will need to override a few components in order to do that, starting from UserLogic#update and following the flow. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Re: Propagation failure on update
- Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schw...@in2p3.fr a écrit : > - Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgro...@apache.org a > écrit : > >> On 26/03/24 13:30, Lionel SCHWARZ wrote: >>> Dear all, >>> >>> After reading >>> https://syncope.apache.org/docs/reference-guide.html#propagation, >>> I ask myself a question: is there a way to avoid a User (or AnyObject) to be >>> modified in case the propagation task fails? >> >> Hi Lionel, >> that's exactly the purpose of setting a non-null priority onto an External >> Resource: >> >> > the execution of a given set of tasks is halted (and global failure is >> > reported) >> > whenever the first sequential task fails >> >> would mean exactly that. > Thanks Francesco, I'll try this. Hi Francesco and all, After investigations and tests, I could indeed check that the sequence of tasks stops when the first task fails. But there is a remaining question: the attribute on the Entity itself (the USER), the one which triggered the propagation, keeps changed. So we are in the situation where the User has an attribute different than values in the remote repos. Is there a way to do kind of rollback on the USER update in this case? Lionel smime.p7s Description: S/MIME Cryptographic Signature
Re: Propagation failure on update
- Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgro...@apache.org a écrit : > On 26/03/24 13:30, Lionel SCHWARZ wrote: >> Dear all, >> >> After reading >> https://syncope.apache.org/docs/reference-guide.html#propagation, >> I ask myself a question: is there a way to avoid a User (or AnyObject) to be >> modified in case the propagation task fails? > > Hi Lionel, > that's exactly the purpose of setting a non-null priority onto an External > Resource: > > > the execution of a given set of tasks is halted (and global failure is > > reported) > > whenever the first sequential task fails > > would mean exactly that. Thanks Francesco, I'll try this. Regards Lionel smime.p7s Description: S/MIME Cryptographic Signature
Re: Propagation failure on update
On 26/03/24 13:30, Lionel SCHWARZ wrote: Dear all, After reading https://syncope.apache.org/docs/reference-guide.html#propagation, I ask myself a question: is there a way to avoid a User (or AnyObject) to be modified in case the propagation task fails? Hi Lionel, that's exactly the purpose of setting a non-null priority onto an External Resource: > the execution of a given set of tasks is halted (and global failure is reported) whenever the first sequential task fails would mean exactly that. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/
Propagation failure on update
Dear all, After reading https://syncope.apache.org/docs/reference-guide.html#propagation, I ask myself a question: is there a way to avoid a User (or AnyObject) to be modified in case the propagation task fails? Regards Lionel smime.p7s Description: S/MIME Cryptographic Signature