ਏਜੰਟ ਦੇ ਸਾਈਡ ਅਸਰਾਂ ਲਈ ਆਟੋਮੈਟਿਕ ਰੋਲਬੈਕ

ਏਜੰਟ ਦਾ ਰੋਲਬੈਕ ਕੋਡ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਚੁਣਿਆ ਡਾਟਾ ਮੁੜ ਬਹਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਹੋਰ ਸੰਸਥਾ ਨੂੰ ਬੇਨਤੀ ਭੁਲਾਉਣ, ਪਹੁੰਚ ਚੁੱਕੀ ਈਮੇਲ ਨੂੰ ਇਨਬਾਕਸ ਵਿੱਚੋਂ ਵਾਪਸ ਖਿੱਚਣ ਜਾਂ ਇਹ ਦਿਖਾਵਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕਾਰਡ ਚਾਰਜ ਕਦੇ ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਰ ਤੱਕ ਪਹੁੰਚਿਆ ਹੀ ਨਹੀਂ ਸੀ। ਜੋ ਟੀਮਾਂ ਇਨ੍ਹਾਂ ਸਭ ਕਾਰਵਾਈਆਂ ਨੂੰ «ਰੋਲਬੈਕ» ਕਹਿੰਦੀਆਂ ਹਨ, ਉਹ ਅਜਿਹਾ ਦਿਲਾਸਾ ਦੇਣ ਵਾਲਾ ਕੰਟਰੋਲ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਅਹਿਮ ਵੇਲੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸੁਰੱਖਿਅਤ ਡਿਜ਼ਾਈਨ ਚਾਰ ਤਰੀਕਿਆਂ ਨੂੰ ਵੱਖ ਰੱਖਦਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਸਨੈਪਸ਼ਾਟ, Git revert, ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਅਤੇ ਮੁਆਵਜ਼ਾ ਦੇਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ। ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਹੱਦ ਹੈ। ਜੋ ਵੀ ਕਾਰਵਾਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਹੱਦ ਪਾਰ ਕਰਦੀ ਹੈ, ਏਜੰਟ ਵੱਲੋਂ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਲਈ ਵੱਖਰੀ ਮਨਜ਼ੂਰੀ, ਸਬੂਤ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦਾ ਨਿਯਮ ਅਤੇ ਰਿਕਵਰੀ ਰਸਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਕੋਈ ਉਸ ਰਸਤੇ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਬਿਆਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਕਾਰਵਾਈ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਦੇ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ।

ਰੋਲਬੈਕ ਦੇ ਚਾਰ ਵੱਖਰੇ ਅਰਥ ਹਨ

ਰੋਲਬੈਕ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਟੀਮ ਉਸ ਹਾਲਤ ਦਾ ਨਾਮ ਲਵੇ ਜਿਸਨੂੰ ਉਹ ਬਹਾਲ ਕਰੇਗੀ ਅਤੇ ਉਸ ਹਾਲਤ ਦਾ ਵੀ ਜਿਸਨੂੰ ਉਹ ਛੂਹ ਨਹੀਂ ਸਕਦੀ। ਇਹ ਸ਼ਬਦ ਅਕਸਰ ਚਾਰ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਗਾਰੰਟੀਆਂ ਬਹੁਤ ਵੱਖਰੀਆਂ ਹਨ।

ਸਨੈਪਸ਼ਾਟ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਵਰਕਸਪੇਸ ਦੀ ਸੰਭਾਲੀ ਹੋਈ ਵਰਜਨ ਬਹਾਲ ਕਰਦਾ ਹੈ। ਉਤਪਾਦ ਦੇ ਅਨੁਸਾਰ, ਇਸ ਵਿੱਚ ਬਣਿਆ ਕੋਡ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਤੇ ਚੁਣੀ ਪ੍ਰਬੰਧਿਤ ਹਾਲਤ ਹੋ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਤੱਕ ਸਨੈਪਸ਼ਾਟ ਦਾ ਕਾਂਟ੍ਰੈਕਟ ਖੁੱਲ੍ਹ ਕੇ ਨਾ ਕਹੇ, ਇਹ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

Git revert ਇੱਕ ਨਵੀਂ ਕਮਿਟ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ ਜਿਸਦੇ ਬਦਲਾਅ ਪਿਛਲੀ ਕਮਿਟ ਦੇ ਬਦਲਾਅ ਉਲਟ ਦਿੰਦੇ ਹਨ। ਇਹ ਸਰੋਤ ਇਤਿਹਾਸ ਨੂੰ ਮਿਟਾਏ ਬਿਨਾਂ ਠੀਕ ਕਰਦਾ ਹੈ। ਜਿਸ ਵੇਲੇ ਪੁਰਾਣਾ ਕੋਡ ਚੱਲ ਰਿਹਾ ਸੀ, ਉਸਨੇ ਜਿਨ੍ਹਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਕਾਲ ਕੀਤਾ ਸੀ, ਉਨ੍ਹਾਂ ਨਾਲ ਇਸਦਾ ਕੋਈ ਸੰਪਰਕ ਨਹੀਂ ਹੁੰਦਾ।

ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਡਾਟਾਬੇਸ ਵਿੱਚ ਰੱਖੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਬਦਲਦੀ ਹੈ। ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਰੋਲਬੈਕ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਨਾ-ਕਮਿਟ ਹੋਈਆਂ ਲਿਖਤਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਬੈਕਅੱਪ ਬਹਾਲ ਕਰਨਾ ਜਾਂ point-in-time recovery ਵਰਤਣਾ ਇਸ ਤੋਂ ਕਿਤੇ ਵੱਡੀ ਕਾਰਵਾਈ ਹੈ, ਜੋ ਡਾਟਾਬੇਸ ਕਲੱਸਟਰ ਨੂੰ ਪੁਰਾਣੀ ਹਾਲਤ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਾਰਵਾਈ ਉਸ ਡਾਟਾਬੇਸ ਤੋਂ ਬਾਹਰ ਦੇ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਮਿਲਾਨ ਨਹੀਂ ਕਰਦੀ।

ਮੁਆਵਜ਼ਾ ਦੇਣ ਵਾਲੀ ਕਾਰਵਾਈ ਨਵਾਂ ਅਸਰ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਪੁਰਾਣੇ ਅਸਰ ਨੂੰ ਬੇਅਸਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਰਿਫੰਡ ਕੈਪਚਰ ਹੋਏ ਭੁਗਤਾਨ ਦਾ ਮੁਆਵਜ਼ਾ ਹੈ। ਰੱਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਆਰਡਰ ਦਾ ਮੁਆਵਜ਼ਾ ਹੈ। ਸੁਧਾਰਕ ਈਮੇਲ ਗਲਤ ਈਮੇਲ ਦਾ ਨੁਕਸਾਨ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਪਹਿਲਾ ਸੁਨੇਹਾ ਹਟਾ ਨਹੀਂ ਸਕਦੀ। ਮੁਆਵਜ਼ਾ ਇਸ ਅਸੁਖਾਵੀਂ ਸੱਚਾਈ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ ਕਿ ਅਸਲ ਕਾਰਵਾਈ ਹੋਈ ਸੀ।

ਮੈਂ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਦੌਰਾਨ ਅਸਰ ਮਲਕੀਅਤ ਸਾਰਣੀ ਵਰਤਦਾ ਹਾਂ ਕਿਉਂਕਿ ਇਹ ਸਪਸ਼ਟ ਜਵਾਬ ਲੈਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ:

ਆਖ਼ਰੀ ਕਾਲਮ ਸਭ ਤੋਂ ਅਹਿਮ ਹੈ। ਉਲਟੀ ਕਾਰਵਾਈ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਅਸਲ ਕਾਰਵਾਈ ਗਾਇਬ ਹੋ ਗਈ। ਆਡਿਟ ਰਿਕਾਰਡ, ਪ੍ਰਾਪਤਕਰਤਾ ਦੀਆਂ ਕਾਪੀਆਂ, ਸੈਟਲਮੈਂਟ ਐਂਟਰੀਆਂ, ਵੈੱਬਹੁੱਕ ਅਤੇ ਭੌਤਿਕ ਕੰਮ ਬਾਕੀ ਰਹਿ ਸਕਦੇ ਹਨ।

ਕੋਡ revert ਪ੍ਰੋਗਰਾਮ ਬਦਲਦਾ ਹੈ, ਬੀਤਿਆ ਸਮਾਂ ਨਹੀਂ

ਕੋਡ revert ਭਵਿੱਖ ਦੇ ਵਿਹਾਰ ਨੂੰ ਰੋਕਦਾ ਜਾਂ ਬਦਲਦਾ ਹੈ। ਪੁਰਾਣੀ ਵਰਜਨ ਦੇ ਪਹਿਲਾਂ ਹੀ ਪੈਦਾ ਕੀਤੇ ਵਿਹਾਰ ਨੂੰ ਇਹ ਉਲਟਦਾ ਨਹੀਂ। ਟੀਮ Git, ਪਲੇਟਫਾਰਮ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਡਿਪਲੌਇਮੈਂਟ ਰੋਲਬੈਕ ਜੋ ਵੀ ਵਰਤੇ, ਇਹ ਗੱਲ ਸਹੀ ਰਹਿੰਦੀ ਹੈ।

Git ਦਸਤਾਵੇਜ਼ git revert ਨੂੰ ਅਜਿਹੀਆਂ ਕਮਿਟਾਂ ਰਿਕਾਰਡ ਕਰਨ ਵਜੋਂ ਦੱਸਦੇ ਹਨ ਜੋ ਪਿਛਲੀਆਂ ਕਮਿਟਾਂ ਦੇ ਬਦਲਾਅ ਉਲਟ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਸ਼ਬਦਾਵਲੀ ਬਿਲਕੁਲ ਸਹੀ ਹੈ: Git ਰਿਪੋਜ਼ਟਰੀ ਸਮੱਗਰੀ ਉੱਤੇ ਉਲਟ ਪੈਚ ਲਗਾਉਂਦਾ ਹੈ। ਜਦੋਂ reverted ਕਮਿਟ ਚੱਲੀ ਸੀ, ਬਣੀਆਂ ਈਮੇਲਾਂ, ਭੁਗਤਾਨਾਂ, ਕਲਾਉਡ ਸਰੋਤਾਂ, ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਜਾਂ ਭਾਈਵਾਲ API ਬੇਨਤੀਆਂ ਬਾਰੇ Git ਨੂੰ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ।

ਮੰਨੋ ਏਜੰਟ ਬਿਲਿੰਗ ਫੰਕਸ਼ਨ ਬਦਲਦਾ ਹੈ, ਇਸਨੂੰ ਡਿਪਲੌਇ ਕਰਦਾ ਹੈ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਖ਼ਰਾਬੀ ਫੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਦੋ ਵਾਰ ਚਲਾਉਂਦਾ ਹੈ। ਕਮਿਟ revert ਕਰਨ ਨਾਲ ਗਲਤ ਫੰਕਸ਼ਨ ਮੁੜ ਚੱਲਣ ਤੋਂ ਰੁਕ ਸਕਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਸੈਸਰ ਕੋਲ ਭੁਗਤਾਨ ਦੀਆਂ ਦੋ ਕੋਸ਼ਿਸ਼ਾਂ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਸਥਾਨਕ ਡਾਟਾਬੇਸ ਨੇ ਸਿਰਫ਼ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਰਿਕਾਰਡ ਕੀਤੀ ਹੋਵੇ, ਤਾਂ revert ਦੂਜੇ ਜਵਾਬ ਨੂੰ ਸਮਝਣ ਵਾਲਾ ਕੋਡ ਰਸਤਾ ਹਟਾ ਕੇ ਜਾਂਚ ਹੋਰ ਔਖੀ ਕਰ ਸਕਦਾ ਹੈ।

ਡਿਪਲੌਇਮੈਂਟ ਰੋਲਬੈਕ ਦੀ ਵੀ ਇਹੋ ਹੱਦ ਹੈ। ਟ੍ਰੈਫਿਕ ਨੂੰ ਪੁਰਾਣੀ ਬਿਲਡ ਵੱਲ ਮੋੜਨ ਨਾਲ ਚੱਲਣਯੋਗ ਵਿਹਾਰ ਬਹਾਲ ਹੁੰਦਾ ਹੈ। ਬਦਲੀ ਗਈ ਬਿਲਡ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਨਤੀਜੇ ਕਾਇਮ ਰਹਿੰਦੇ ਹਨ। ਕਤਾਰਬੱਧ ਜੌਬ ਵੀ ਡਿਪਲੌਇਮੈਂਟ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ ਅਤੇ ਬਹਾਲ ਵਰਜਨ ਉੱਤੇ ਪੁਰਾਣੀਆਂ ਧਾਰਣਾਵਾਂ ਨਾਲ ਚੱਲ ਸਕਦੇ ਹਨ।

Revert ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀ ਬਿਲਡ ਦੇ ਬਣਾਏ ਓਪਰੇਸ਼ਨਲ ਸਬੂਤ ਬਚਾਓ:

• ਡਿਪਲੌਇਮੈਂਟ ਪਛਾਣਕਰਤਾ ਅਤੇ ਸਰੋਤ ਕਮਿਟ
• ਏਜੰਟ ਰਨ ਅਤੇ ਇਰਾਦਾ ਪਛਾਣਕਰਤਾ
• ਕਤਾਰ ਸੁਨੇਹਾ ਪਛਾਣਕਰਤਾ ਅਤੇ ਲੀਜ਼ ਸਥਿਤੀ
• ਬਾਹਰੀ ਬੇਨਤੀ ਪਛਾਣਕਰਤਾ
• ਪ੍ਰਦਾਤਾ ਦੇ ਜਵਾਬ ਅਤੇ ਟਾਈਮਸਟੈਂਪ

ਫਿਰ ਨਵੀਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਰੋਕੋ, ਅਧੂਰੀਆਂ ਕਾਰਵਾਈਆਂ ਦਾ ਮਿਲਾਨ ਕਰੋ ਅਤੇ ਕੋਡ ਬਹਾਲ ਕਰੋ। ਪਹਿਲਾਂ revert ਕਰਕੇ ਬਾਅਦ ਵਿੱਚ ਸਵਾਲ ਪੁੱਛਣ ਨਾਲ ਇਹ ਸਮਝਣ ਦਾ ਸਭ ਤੋਂ ਸੌਖਾ ਰਸਤਾ ਨਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਅਸਰ ਹੱਦ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਗਏ।

ਸਨੈਪਸ਼ਾਟ Git ਕਮਿਟ ਨਾਲੋਂ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਨਿਯਮ ਉਹੀ ਹੈ। ਸਨੈਪਸ਼ਾਟ ਕਾਂਟ੍ਰੈਕਟ ਨੂੰ ਠੀਕ-ਠੀਕ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਕਿਹੜੇ ਸਰੋਤ ਹਨ। ਜੇ ਇਸ ਵਿੱਚ ਕੋਡ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕੋਡ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਰਿਕਵਰੀ ਤਰੀਕਾ ਕਹੋ। ਇੰਟਰਫੇਸ ਦੀ ਆਸ ਭਰੀ ਭਾਸ਼ਾ ਨਾਲ ਇਸਨੂੰ ਸਰਵਭੌਮ ਅਨਡੂ ਨਾ ਬਣਾਓ।

ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਦਾ ਕੰਮ ਲੋਕਾਂ ਦੀ ਸੋਚ ਨਾਲੋਂ ਛੋਟਾ ਹੈ

ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਡਾਟਾਬੇਸ ਦੀ ਹਾਲਤ ਬਹਾਲ ਕਰਦੀ ਹੈ, ਲੈਣ-ਦੇਣ ਦੇ ਹਰ ਭਾਗੀਦਾਰ ਦੀ ਕਾਰੋਬਾਰੀ ਹਕੀਕਤ ਨਹੀਂ। ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਇੱਕ ਡਾਟਾਬੇਸ ਅੰਦਰ ਐਟਾਮਿਕ ਹੋ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਕਾਰਵਾਈ ਕਈ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵੰਡੀ ਰਹਿੰਦੀ ਹੈ।

ਇਹ ਕ੍ਰਮ ਵੇਖੋ:

1. ਏਜੰਟ ਇਨਵੌਇਸ ਕਤਾਰ ਪਾਉਂਦਾ ਹੈ।
2. ਇਹ ਭੁਗਤਾਨ API ਕਾਲ ਕਰਦਾ ਹੈ।
3. ਪ੍ਰੋਸੈਸਰ ਚਾਰਜ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।
4. ਡਾਟਾਬੇਸ ਕਮਿਟ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸਥਾਨਕ ਰੋਲਬੈਕ ਇਨਵੌਇਸ ਕਤਾਰ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਚਾਰਜ ਫਿਰ ਵੀ ਮੌਜੂਦ ਹੈ। ਮਿਲਾਨ ਕੀਤੇ ਬਿਨਾਂ ਪੂਰੀ ਕਾਰਵਾਈ ਦੁਹਰਾਉਣ ਨਾਲ ਗਾਹਕ ਤੋਂ ਫਿਰ ਚਾਰਜ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ classic dual write failure ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਇੱਕ ਕਾਰੋਬਾਰੀ ਕਾਰਵਾਈ ਐਟਾਮਿਕ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਿਨ੍ਹਾਂ ਦਾ ਸਾਂਝਾ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਕੋਆਰਡੀਨੇਟਰ ਨਹੀਂ ਹੈ।

ਕ੍ਰਮ ਉਲਟਣ ਨਾਲ ਵੀ ਹੱਲ ਨਹੀਂ ਨਿਕਲਦਾ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਪਹਿਲਾਂ ਇਨਵੌਇਸ ਕਮਿਟ ਕਰੇ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਭੁਗਤਾਨ ਕਾਲ ਫੇਲ ਹੋ ਜਾਵੇ, ਡਾਟਾਬੇਸ ਵਿੱਚ ਅਦਾ ਨਾ ਹੋਇਆ ਇਨਵੌਇਸ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਹਾਲਤ ਦੀ ਜਾਂਚ ਸੌਖੀ ਹੈ, ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਫਿਰ ਵੀ ਅਜਿਹੀ state machine ਚਾਹੀਦੀ ਹੈ ਜੋ payment_pending, payment_confirmed, payment_failed ਅਤੇ payment_unknown ਵਿੱਚ ਫਰਕ ਕਰੇ।

PostgreSQL ਦਸਤਾਵੇਜ਼ point-in-time recovery ਨੂੰ ਬੇਸ ਬੈਕਅੱਪ ਬਹਾਲ ਕਰਕੇ ਅਤੇ write ahead log ਰਿਕਾਰਡਾਂ ਨੂੰ ਚੁਣੇ ਹੋਏ recovery target ਤੱਕ ਦੁਬਾਰਾ ਚਲਾ ਕੇ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਕਾਰਵਾਈ ਦੱਸਦੇ ਹਨ। ਇਹ ਡਾਟਾਬੇਸ ਕਲੱਸਟਰ ਬਹਾਲ ਕਰਨ ਲਈ ਓਪਰੇਟਰ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਇਹ ਇੱਕ ਏਜੰਟ ਰਨ ਲਈ ਚੁਣਿੰਦਾ ਅਨਡੂ ਨਹੀਂ, ਅਤੇ ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਰ ਜਾਂ ਮੇਲ ਸੇਵਾ ਨੂੰ ਉਸੇ ਟਾਈਮਸਟੈਂਪ ਉੱਤੇ ਵਾਪਸ ਜਾਣ ਲਈ ਨਹੀਂ ਕਹਿ ਸਕਦੀ।

ਡਾਟਾਬੇਸ ਨੂੰ ਪਿੱਛੇ ਲਿਜਾਣ ਨਾਲ ਦੂਜਾ ਬੇਮੇਲ ਵੀ ਬਣ ਸਕਦਾ ਹੈ। ਮੰਨੋ ਆਉਟੇਜ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ 10:00 ਵਜੇ ਦੀ ਹਾਲਤ ਬਹਾਲ ਕਰਦੇ ਹੋ। ਪ੍ਰਦਾਤਾ ਨੇ 10:07 ਵਜੇ ਤੱਕ ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ, ਪਰ ਬਹਾਲ ਡਾਟਾਬੇਸ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦੇ ਰਿਕਾਰਡ ਨਹੀਂ ਰਹੇ। ਜਿਨ੍ਹਾਂ ਏਜੰਟਾਂ ਨੂੰ ਕਤਾਰਾਂ «ਗੁੰਮ» ਦਿਖਦੀਆਂ ਹਨ, ਉਹ ਸੱਤ ਮਿੰਟ ਦਾ ਸਾਰਾ ਕੰਮ ਮੁੜ ਬਣਾ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਵਰਕਰ ਮੁੜ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਕਵਰੀ ਨੂੰ ਬਾਹਰੀ ਮਿਲਾਨ ਪੜਾਅ ਚਾਹੀਦਾ ਹੈ।

Outbox pattern ਇੱਕ ਖ਼ਤਰਨਾਕ ਖਾਲੀ ਥਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਆਪਣਾ ਕਾਰੋਬਾਰੀ ਬਦਲਾਅ ਅਤੇ ਅਸਰ ਦਾ ਇਰਾਦਾ ਇੱਕੋ ਸਥਾਨਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਿੱਚ ਕਮਿਟ ਕਰਦੀ ਹੈ:

BEGIN;

INSERT INTO invoices (invoice_id, customer_id, status)
VALUES ('inv_2048', 'cust_91', 'payment_pending');

INSERT INTO effect_intents
  (intent_id, operation, subject_id, status)
VALUES
  ('eff_7f31', 'capture_payment', 'inv_2048', 'pending');

COMMIT;

ਬਾਅਦ ਵਿੱਚ ਵਰਕਰ eff_7f31 ਕਲੇਮ ਕਰਦਾ ਹੈ, ਸਥਿਰ idempotency ਮੁੱਲ ਨਾਲ ਪ੍ਰਦਾਤਾ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜਾ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। Outbox ਬਾਹਰੀ ਕਾਲ ਨੂੰ ਐਟਾਮਿਕ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਸਿਸਟਮ ਨੂੰ ਟਿਕਾਊ ਸਬੂਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕੰਮ ਦਾ ਇਰਾਦਾ ਸੀ, ਜਿਸ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਅਤੇ ਮਿਲਾਨ ਸੰਭਵ ਹੁੰਦਾ ਹੈ।

ਬਾਹਰੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਮੁਆਵਜ਼ਾ ਚਾਹੀਦਾ ਹੈ, ਤੇ ਕੁਝ ਦਾ ਕੋਈ ਮੁਆਵਜ਼ਾ ਨਹੀਂ ਹੁੰਦਾ

ਬਾਹਰੀ side effect ਲਈ ਪ੍ਰਦਾਤਾ-ਖਾਸ ਮੁਆਵਜ਼ਾ ਜਾਂ ਇਹ ਸਪਸ਼ਟ ਬਿਆਨ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਰਥਪੂਰਨ ਮੁਆਵਜ਼ਾ ਮੌਜੂਦ ਨਹੀਂ। ਹਰ ਕਾਰਵਾਈ ਨੂੰ ਉਲਟ ਸਕਣ ਯੋਗ ਸਮਝਣਾ, ਇਹ ਮੰਨਣ ਨਾਲੋਂ ਵੀ ਮਾੜਾ ਹੈ ਕਿ ਕੁਝ ਕਾਰਵਾਈਆਂ ਲਈ ਮਨਜ਼ੂਰੀ ਚਾਹੀਦੀ ਹੈ।

ਈਮੇਲ ਸਭ ਤੋਂ ਸੌਖੀ ਮਿਸਾਲ ਹੈ। ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਸੁਨੇਹਾ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕਤਾਰਬੱਧ ਜੌਬ ਰੱਦ ਕਰ ਸਕਦੀ ਹੈ। ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪ੍ਰਦਾਤਾ ਥੋੜ੍ਹੇ ਅੰਦਰੂਨੀ ਪੜਾਅ ਦੌਰਾਨ ਰੱਦ ਕਰਨ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਪ੍ਰਾਪਤਕਰਤਿਆਂ ਅਤੇ ਮੇਲ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਆਮ recall ਗਾਰੰਟੀ ਨਹੀਂ ਹੁੰਦੀ। ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ ਦੂਜਾ ਸੁਨੇਹਾ ਰਿਕਾਰਡ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ, ਪਹਿਲਾ ਮਿਟਾ ਨਹੀਂ ਸਕਦਾ। ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ, ਕਾਨੂੰਨੀ ਨੋਟਿਸ ਅਤੇ ਸਾਖ ਦਾ ਨੁਕਸਾਨ ਸਾਹਮਣੇ ਹੀ ਰਹਿੰਦੇ ਹਨ।

ਭੁਗਤਾਨਾਂ ਦੀਆਂ ਕਈ ਹਾਲਤਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੀਮਾਂ ਅਕਸਰ «ਚਾਰਜ ਹੋ ਗਿਆ» ਕਹਿ ਕੇ ਜੋੜ ਦਿੰਦੀਆਂ ਹਨ। ਅਥਾਰਾਈਜ਼ੇਸ਼ਨ ਖਰਚ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਰਾਖਵੀਂ ਕਰਦੀ ਹੈ। Capture ਉਸ ਅਥਾਰਾਈਜ਼ੇਸ਼ਨ ਦੇ ਆਧਾਰ ਉੱਤੇ ਰਕਮ ਭੇਜਣ ਦੀ ਬੇਨਤੀ ਹੈ। ਜਿਹੜੀ ਅਥਾਰਾਈਜ਼ੇਸ਼ਨ ਹਾਲੇ ਸੈਟਲ ਨਹੀਂ ਹੋਈ, ਉਸਨੂੰ void ਕਰਨ ਨਾਲ ਰਿਲੀਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। Refund capture ਤੋਂ ਬਾਅਦ ਪੈਸਾ ਵਾਪਸ ਕਰਨ ਲਈ ਬਾਅਦ ਦੀ ਵਿੱਤੀ ਐਂਟਰੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਕਾਰਵਾਈਆਂ ਦੀ ਟਾਈਮਿੰਗ, ਫੀਸ, ਅਧਿਕਾਰ ਅਤੇ ਗਾਹਕ ਉੱਤੇ ਅਸਰ ਵੱਖਰੇ ਹਨ। ਆਮ undo_payment ਟੂਲ ਉਹ ਜਾਣਕਾਰੀ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਏਜੰਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈ ਲਈ ਲੋੜ ਹੈ।

ਹੋਰ APIs ਇਸ ਤੋਂ ਵੀ ਘੱਟ ਸਹਿਯੋਗੀ ਹਨ। ਕੋਈ ਬੇਨਤੀ ਇਨਵੈਂਟਰੀ ਮੰਗਵਾ ਸਕਦੀ ਹੈ, ਇਨਫਰਾਸਟ੍ਰੱਕਚਰ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰ ਸਕਦੀ ਹੈ, ਸਮੱਗਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਪਹੁੰਚ ਦੇ ਸਕਦੀ ਹੈ, ਪੈਕੇਜ ਭੇਜ ਸਕਦੀ ਹੈ ਜਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੀ ਹੈ। DELETE endpoint ਉਲਟੇ ਜਾ ਸਕਣ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਸਰੋਤ ਮਿਟਾਉਣ ਨਾਲ ਆਡਿਟ ਲਾਗ, ਕਾਪੀ ਕੀਤਾ ਡਾਟਾ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਨਿਰਭਰ ਸਰੋਤ ਜਾਂ ਭੌਤਿਕ ਨਤੀਜੇ ਰਹਿ ਸਕਦੇ ਹਨ।

ਮੁਆਵਜ਼ੇ ਨੂੰ ਉਸ ਅਧਾਰ ਤੇ ਵਰਗੀਕ੍ਰਿਤ ਕਰੋ ਜੋ ਇਹ ਇਮਾਨਦਾਰੀ ਨਾਲ ਕਰ ਸਕਦਾ ਹੈ:

• ਸਹੀ ਸਥਾਨਕ ਉਲਟਾ ਨਿਯੰਤਰਿਤ ਹਾਲਤ ਨੂੰ ਪੁਰਾਣੇ ਮੁੱਲ ਉੱਤੇ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ।
• ਪ੍ਰਦਾਤਾ ਰੱਦਕਰਨ ਉਹ ਕੰਮ ਰੋਕਦਾ ਹੈ ਜੋ ਹਾਲੇ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ।
• ਵਿੱਤੀ ਮੁਆਵਜ਼ਾ ਰਿਫੰਡ ਜਾਂ ਕ੍ਰੈਡਿਟ ਬਣਾਉਂਦਾ ਹੈ।
• ਸੁਧਾਰਕ ਸੰਚਾਰ ਮੰਨਦਾ ਹੈ ਕਿ ਪਹਿਲਾ ਸੁਨੇਹਾ ਹਾਲੇ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
• ਹੱਥੋਂ ਕੀਤੀ ਮੁਰੰਮਤ ਉਹ ਅਸਰ ਸੰਭਾਲਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸੰਦਰਭ ਸੁਰੱਖਿਅਤ ਆਟੋਮੈਟਿਕ ਨਿਯਮ ਵਿੱਚ ਨਹੀਂ ਆ ਸਕਦਾ।

ਮੁਆਵਜ਼ਾ ਵੀ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਰਿਫੰਡ endpoint ਟਾਈਮਆਉਟ ਹੋ ਸਕਦਾ ਹੈ। ਰੱਦਕਰਨ ਦੀ ਮਿਆਦ ਮੁੱਕ ਸਕਦੀ ਹੈ। ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਪਤਾ ਸੁਧਾਰਕ ਸੁਨੇਹਾ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਏਜੰਟ ਕੋਲ ਵਰਤੇ ਖਾਤੇ ਨੂੰ ਇਜਾਜ਼ਤ ਨਾ ਹੋਵੇ। ਇਸ ਲਈ ਸਿਸਟਮ ਨੂੰ ਮੁਆਵਜ਼ੇ ਨੂੰ ਵੀ ਵੱਖਰੀ ਕਾਰਵਾਈ ਵਜੋਂ ਟ੍ਰੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਆਪਣੇ ਇਰਾਦਾ ਪਛਾਣਕਰਤਾ, ਸਥਿਤੀ, ਕੋਸ਼ਿਸ਼ਾਂ, ਸਬੂਤ ਅਤੇ ਮਨਜ਼ੂਰੀ ਨੀਤੀ ਸਮੇਤ।

«ਰੋਲਬੈਕ ਦਾ ਰੋਲਬੈਕ» ਜਿਹੀ recursive ਸੁਵਿਧਾ ਨਾ ਬਣਾਓ। ਇਤਿਹਾਸ ਨੂੰ ਕਾਰਵਾਈਆਂ ਦੇ ledger ਵਜੋਂ ਮਾਡਲ ਕਰੋ। ਜੇ ਮੁਆਵਜ਼ਾ ਨਵੀਂ ਗਲਤੀ ਪੈਦਾ ਕਰੇ, ਤਾਂ ਮੌਜੂਦਾ ਹਾਲਤ ਦੀ ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ ਹੋਰ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਜਾਰੀ ਕਰੋ। ਇਤਿਹਾਸ ਲੰਮਾ ਹੁੰਦਾ ਹੈ, ਪਰ incident ਦੌਰਾਨ ਸਮਝ ਆਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।

Idempotency ਦੁਹਰਾਵੇ ਰੋਕਦੀ ਹੈ, ਸਫਲਤਾ ਉਲਟਦੀ ਨਹੀਂ

Idempotency ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਦੁਹਰਾਏ ਹੋਏ ਮਨਚਾਹੇ ਅਸਰ ਬਣਾਉਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਇਹ ਪਹਿਲੇ ਸਫਲ ਅਸਰ ਨੂੰ ਅਨਡੂ ਨਹੀਂ ਕਰਦੀ। ਟੀਮਾਂ ਅਕਸਰ ਇਨ੍ਹਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਟਾਈਮਆਉਟ ਤੋਂ ਬਾਅਦ ਫ਼ਰਕ ਸਮਝਦੀਆਂ ਹਨ।

RFC 9110 idempotent request method ਨੂੰ ਅਜਿਹੇ method ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਈ ਇੱਕੋ ਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਮਨਚਾਹਾ ਅਸਰ, ਇੱਕ ਅਜਿਹੀ ਬੇਨਤੀ ਦੇ ਅਸਰ ਵਰਗਾ ਹੋਵੇ। ਇਹ protocol semantics ਪੱਧਰ ਉੱਤੇ PUT, DELETE ਅਤੇ safe methods ਨੂੰ idempotent ਦੱਸਦਾ ਹੈ। POST ਆਮ ਤੌਰ ਤੇ idempotent ਨਹੀਂ ਹੁੰਦਾ, ਭਾਵੇਂ API ਆਪਣੇ ਕਾਂਟ੍ਰੈਕਟ ਰਾਹੀਂ idempotency ਵਿਹਾਰ ਜੋੜ ਸਕਦੀ ਹੈ।

ਇਹ ਸ਼ਰਤ ਅਹਿਮ ਹੈ। Idempotent DELETE ਵੀ ਹਰ ਵਾਰ ਨਵੀਂ ਲਾਗ ਐਂਟਰੀ, ਮੈਟਰਿਕ ਜਾਂ ਜਵਾਬ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਦਾ idempotency implementation ਰਿਕਾਰਡਾਂ ਦੀ ਮਿਆਦ ਵੀ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਇੱਕ ਖਾਤੇ ਤੱਕ ਸੀਮਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਬਦਲੇ ਪੈਰਾਮੀਟਰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਚੁਣੇ ਨਤੀਜੇ cache ਕਰ ਸਕਦਾ ਹੈ। HTTP verb ਤੋਂ ਗਾਰੰਟੀ ਅਨੁਮਾਨਣ ਦੀ ਥਾਂ ਪ੍ਰਦਾਤਾ ਕਾਂਟ੍ਰੈਕਟ ਪੜ੍ਹੋ।

ਹਰ effect intent ਨੂੰ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਥਿਰ idempotency ਮੁੱਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਸੇ intent ਦੀਆਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ ਉਹੀ ਮੁੱਲ ਵਰਤਣ। ਨਵੇਂ ਕਾਰੋਬਾਰੀ intent ਨੂੰ ਨਵਾਂ ਮੁੱਲ ਮਿਲੇ। ਇਸਨੂੰ ਸਿਰਫ਼ ਗਾਹਕ, ਰਕਮ ਅਤੇ ਤਾਰੀਖ ਵਰਗੇ ਬਦਲ ਸਕਣ ਵਾਲੇ ਪੈਰਾਮੀਟਰਾਂ ਤੋਂ ਕਦੇ ਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ ਦੋ ਵੈਧ ਖਰੀਦਾਂ ਵਿੱਚ ਇਹ ਮੁੱਲ ਇੱਕੋ ਹੋ ਸਕਦੇ ਹਨ।

ਟਾਈਮਆਉਟ ਅਣਜਾਣ ਨਤੀਜਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਸਫਲਤਾ ਨਹੀਂ। ਇਹ ਕ੍ਰਮ ਵਰਤੋ:

1. ਕੋਸ਼ਿਸ਼ ਨੂੰ outcome_unknown ਮਾਰਕ ਕਰੋ, ਬਦਲਵਾਂ intent ਨਾ ਬਣਾਓ।
2. Idempotency ਮੁੱਲ ਜਾਂ ਓਪਰੇਸ਼ਨ ਹਵਾਲੇ ਨਾਲ ਪ੍ਰਦਾਤਾ ਕੋਲ ਪੁੱਛੋ।
3. ਜੇ ਪ੍ਰਦਾਤਾ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ, ਤਾਂ ਉਹ ਸਫਲਤਾ ਸਥਾਨਕ ਤੌਰ ਤੇ ਰਿਕਾਰਡ ਕਰੋ।
4. ਜੇ ਉਹ ਦੱਸੇ ਕਿ ਕੋਈ ਕਾਰਵਾਈ ਨਹੀਂ ਹੋਈ, ਤਾਂ ਉਸੇ ਮੁੱਲ ਨਾਲ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
5. ਜੇ ਉਹ ਜਵਾਬ ਨਾ ਦੇ ਸਕੇ, ਤਾਂ ਕਾਰਵਾਈ ਮਿਲਾਨ ਜਾਂ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਈ ਰੋਕ ਦਿਓ।

ਇਹ ਜਵਾਬ ਰੂਪ ਏਜੰਟ ਨੂੰ ਸਵੀਕਾਰ ਹੋਣ ਅਤੇ transport uncertainty ਵਿੱਚ ਫ਼ਰਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ:

{
  "intent_id": "eff_7f31",
  "attempt": 2,
  "idempotency_key": "eff_7f31",
  "transport_status": "timeout",
  "provider_status": "unknown",
  "provider_reference": null,
  "next_action": "reconcile"
}

ਜਿੱਥੇ ਸਮਰਥਨ ਹੋਵੇ, idempotency ਮੁੱਲ ਲਾਗਾਂ, ਕਤਾਰ ਸੁਨੇਹਿਆਂ, API headers ਅਤੇ ਪ੍ਰਦਾਤਾ metadata ਵਿੱਚੋਂ ਲੰਘਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਓਪਰੇਟਰ ਇਸਨੂੰ ਹੱਦ ਦੇ ਦੋਹਾਂ ਪਾਸਿਆਂ ਉੱਤੇ ਖੋਜ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਰਿਕਵਰੀ ਦੌਰਾਨ ਉਹ ਅਨੁਮਾਨ ਲਗਾਉਣਗੇ।

ਮਨਜ਼ੂਰੀ ਅਸਰ ਦੀ ਹੱਦ ਉੱਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

ਮਨਜ਼ੂਰੀ ਤਦ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਏਜੰਟ ਨੇ ਸਹੀ ਬਾਹਰੀ ਕਾਰਵਾਈ ਬਣਾ ਲਈ ਹੋਵੇ ਅਤੇ ਪਹਿਲੀ ਨਾ-ਉਲਟ ਸਕਣ ਯੋਗ ਬੇਨਤੀ ਸਿਸਟਮ ਤੋਂ ਬਾਹਰ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ। ਵੱਡੇ ਕੰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਉੱਤੇ ਮਨਜ਼ੂਰੀ ਏਜੰਟ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਾਪਤਕਰਤਾ, ਰਕਮ, ਸਕੋਪ ਜਾਂ ਟੂਲ ਬਦਲਣ ਲਈ ਬਹੁਤ ਖੁੱਲ੍ਹ ਦਿੰਦੀ ਹੈ।

«ਇਸ ਗਾਹਕ ਦਾ ਖਾਤਾ ਸੰਭਾਲੋ» ਕਾਰਡ ਚਾਰਜ ਕਰਨ ਜਾਂ ਹਰ ਉਪਭੋਗਤਾ ਨੂੰ ਈਮੇਲ ਭੇਜਣ ਲਈ ਢੁਕਵੀਂ ਮਨਜ਼ੂਰੀ ਨਹੀਂ। ਵੈਧ ਮਨਜ਼ੂਰੀ ਠੋਸ ਕਾਰਵਾਈ ਦੱਸਦੀ ਹੈ: ਪ੍ਰਾਪਤਕਰਤਾ, ਰਕਮ ਅਤੇ ਕਰੰਸੀ, ਸੁਨੇਹੇ ਜਾਂ payload ਦਾ digest, ਟਾਰਗਟ ਖਾਤਾ, ਟੂਲ, ਮਿਆਦ ਅਤੇ ਮਨਜ਼ੂਰ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ। ਮਨਜ਼ੂਰ ਕੀਤਾ ਕੋਈ ਵੀ field ਬਦਲੇ ਤਾਂ ਮਨਜ਼ੂਰੀ ਹੁਣ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ।

ਲਾਭਦਾਇਕ ਨੀਤੀ ਅਸਰਾਂ ਨੂੰ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਏਜੰਟ ਜਾਂ ਮਾਡਲ ਦੀ ਥਾਂ ਨਤੀਜੇ ਦੇ ਆਧਾਰ ਤੇ ਵੰਡਦੀ ਹੈ। Read access ਨਿੱਜੀ ਡਾਟਾ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦੀ ਹੈ, ਪਰ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਕਾਰਵਾਈ ਜਿਹੀ ਰਿਕਵਰੀ ਸਮੱਸਿਆ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਈਮੇਲ ਦਾ ਡਰਾਫਟ ਬਣਾਉਣਾ ਸਥਾਨਕ ਅਤੇ ਉਲਟਣ ਯੋਗ ਹੈ। ਇਸਨੂੰ ਭੇਜਣਾ ਹੱਦ ਪਾਰ ਕਰਦਾ ਹੈ। ਭੁਗਤਾਨ ਪ੍ਰਸਤਾਵ ਬਣਾਉਣਾ ਸਥਾਨਕ ਹੈ। ਰਕਮ capture ਕਰਨਾ ਹੱਦ ਪਾਰ ਕਰਦਾ ਹੈ।

ਇਨ੍ਹਾਂ ਕਾਰਵਾਈਆਂ ਲਈ ਸਪਸ਼ਟ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਕਰੋ ਜੋ:

• ਪੈਸਾ ਹਿਲਾਉਂਦੀਆਂ ਹਨ ਜਾਂ ਵਿੱਤੀ ਜ਼ਿੰਮੇਵਾਰੀ ਬਣਾਉਂਦੀਆਂ ਹਨ
• ਕਿਸੇ ਵਿਅਕਤੀ ਜਾਂ ਬਾਹਰੀ ਸੰਸਥਾ ਨੂੰ ਜਾਣਕਾਰੀ ਭੇਜਦੀਆਂ ਹਨ
• ਨਿਯੰਤਰਿਤ ਸਟੋਰੇਜ ਤੋਂ ਬਾਹਰ ਡਾਟਾ ਪ੍ਰਕਾਸ਼ਿਤ, ਮਿਟਾਉਂਦੀਆਂ ਜਾਂ ਉਜਾਗਰ ਕਰਦੀਆਂ ਹਨ
• ਪਛਾਣ, ਪਹੁੰਚ, ਮਾਲਕੀ ਜਾਂ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗ ਬਦਲਦੀਆਂ ਹਨ
• ਭੌਤਿਕ ਕੰਮ ਜਾਂ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਜਿਸਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਵਾਪਸ ਨਹੀਂ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ

ਘੱਟ ਨਤੀਜੇ ਵਾਲੀਆਂ, ਦੁਹਰਾਈਆਂ ਜਾਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਸੀਮਿਤ standing approval ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸੀਮਾ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਰਕਮ, ਪ੍ਰਾਪਤਕਰਤਾ ਸਮੂਹ, ਮਨਜ਼ੂਰ ਟੂਲ, ਮਿਆਦ, ਦਰ ਅਤੇ ਕੁੱਲ ਕਾਰਵਾਈ ਗਿਣਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। «ਬਿਲਿੰਗ ਲਈ ਮਨਜ਼ੂਰ» ਦੀ ਕੋਈ ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੱਦ ਨਹੀਂ।

ਮਨਜ਼ੂਰੀ ਨੂੰ replay ਤੋਂ ਸੁਰੱਖਿਆ ਵੀ ਚਾਹੀਦੀ ਹੈ। ਇਸਨੂੰ ਕਾਰਵਾਈ ਦੇ immutable digest ਨਾਲ ਬੰਨ੍ਹੋ ਅਤੇ ਜਦੋਂ ਨੀਤੀ ਸਿਰਫ਼ ਇੱਕ execution ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੋਵੇ ਤਾਂ ਇਸਨੂੰ ਵਰਤਿਆ ਹੋਇਆ ਮਾਰਕ ਕਰੋ। ਜੇ execution ਅਣਜਾਣ ਨਤੀਜਾ ਦੇਵੇ, ਨਵੀਂ ਮਨਜ਼ੂਰੀ ਮੰਗ ਕੇ ਦੂਜਾ intent ਨਾ ਬਣਾਓ। ਪਹਿਲਾਂ ਮਨਜ਼ੂਰ intent ਦਾ ਮਿਲਾਨ ਕਰੋ।

ਮਨਜ਼ੂਰੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਰਿਕਵਰੀ ਦੀ ਸੱਚਾਈ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ। «ਡਿਲਿਵਰੀ ਤੋਂ ਬਾਅਦ ਇਹ ਸੁਨੇਹਾ ਵਾਪਸ ਨਹੀਂ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ» ਲਾਭਦਾਇਕ ਹੈ। «ਇਹ ਕਾਰਵਾਈ ਉਲਟੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ» ਗੁੰਮਰਾਹਕੁੰਨ ਹੈ ਜਦੋਂ ਅਸਲ ਰਿਕਵਰੀ ਰਿਫੰਡ ਹੋਵੇ ਜੋ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ ਵਿੱਤੀ ਸਟੇਟਮੈਂਟਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।

ਟੂਲ ਕਾਂਟ੍ਰੈਕਟਾਂ ਵਿੱਚ ਅਸਰ ਦਾ ਪੂਰਾ ਜੀਵਨਚੱਕਰ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ

ਏਜੰਟ ਟੂਲ ਕਾਂਟ੍ਰੈਕਟ ਵਿੱਚ intent, execution, observation ਅਤੇ compensation ਨੂੰ ਵੱਖਰੀਆਂ ਕਾਰਵਾਈਆਂ ਵਜੋਂ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਇੱਕ ਫੰਕਸ਼ਨ ਜੋ ਅਸਰ ਕਰੇ ਅਤੇ success: true ਵਾਪਸ ਦੇਵੇ, ਉਹ retries, approvals ਜਾਂ incident response ਲਈ ਬਹੁਤ ਘੱਟ ਸਬੂਤ ਛੱਡਦਾ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤਾ ਨੀਤੀ ਹਿੱਸਾ ਲਾਗੂ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਛੋਟਾ ਅਤੇ ਸਮੀਖਿਆ ਲਈ ਕਾਫ਼ੀ ਸਪਸ਼ਟ ਹੈ:

tools:
  send_email:
    effect: irreversible
    approval: required
    idempotency_field: intent_id
    evidence_field: provider_message_id
    compensation: null

  capture_payment:
    effect: compensatable
    approval: required
    idempotency_field: intent_id
    evidence_field: provider_payment_id
    compensation: refund_payment

  update_draft:
    effect: local_reversible
    approval: none
    compensation: restore_version

effect planner ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਰਿਕਵਰੀ ਸ਼੍ਰੇਣੀ ਲਾਗੂ ਹੈ। approval ਸਹੀ ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਅਧਿਕਾਰ ਮਿਲਣ ਤੱਕ execution ਰੋਕਦਾ ਹੈ। Idempotency field ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਇੱਕੋ ਪਛਾਣ ਵਰਤਾਉਂਦੀ ਹੈ। Evidence field ਓਪਰੇਟਰਾਂ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਬਚਣਾ ਲਾਜ਼ਮੀ ਹੈ। Compensation field ਵੱਖਰੇ ਟੂਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਇਹ ਦਿਖਾਵਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਅਸਲ ਕਾਲ ਪਿੱਛੇ ਚਲ ਸਕਦੀ ਹੈ।

Execution ਨੂੰ immutable envelope ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

{
  "intent_id": "eff_7f31",
  "operation": "capture_payment",
  "arguments": {
    "invoice_id": "inv_2048",
    "amount_minor": 12900,
    "currency": "USD"
  },
  "approval": {
    "approval_id": "apr_662",
    "scope_hash": "sha256:8b4f...",
    "expires_at": "2026-07-27T18:00:00Z"
  }
}

Executor ਕਾਰਵਾਈ digest ਕੱਢਦਾ ਹੈ, ਇਸਨੂੰ scope_hash ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ, ਮਿਆਦ ਜਾਂਚਦਾ ਹੈ, intent reserve ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਹੀ ਪ੍ਰਦਾਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦਾ ਹੈ। ਇਹ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ metadata ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਵਾਬ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਜੇ ਇਨ੍ਹਾਂ ਲਿਖਤਾਂ ਵਿਚਕਾਰ crash ਹੋ ਜਾਵੇ, ਟਿਕਾਊ intent ਮਿਲਾਨ ਲਈ ਮੌਜੂਦ ਰਹਿੰਦਾ ਹੈ।

Executor ਨੂੰ ਬਿਨਾਂ ਅਟਕਲ ਦੇ ਚਾਰ ਹਾਲਤਾਂ ਰੱਦ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਬਦਲੇ ਆਰਗੂਮੈਂਟ, ਮਿਆਦ ਪੁੱਗੀ ਮਨਜ਼ੂਰੀ, ਵੱਖਰੀ ਕਾਰਵਾਈ ਲਈ intent ਦੀ ਮੁੜ ਵਰਤੋਂ ਅਤੇ ਅਜਿਹੇ ਅਸਰ ਦਾ ਮੁਆਵਜ਼ਾ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਜਿਸਦੀ ਸਫਲ ਪੂਰਨਤਾ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੋਈ। ਏਜੰਟ ਭਰੋਸੇਯੋਗ ਲੱਗਣ ਵਾਲੇ ਅਗਲੇ ਕਦਮ ਲੱਭਣ ਵਿੱਚ ਚੰਗੇ ਹਨ। ਵਿੱਤੀ ਅਤੇ ਸੰਚਾਰ ਕੰਟਰੋਲਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਅਨੁਮਾਨ ਨਾਲੋਂ ਸਪਸ਼ਟ ਰੁਕਾਵਟ ਚੁਣਨੀ ਚਾਹੀਦੀ ਹੈ।

Observation ਲਈ ਵੱਖਰਾ ਟੂਲ ਦਿਓ, ਜਿਵੇਂ get_payment_status(intent_id)। Observation ਨਾਲ ਕੋਈ ਅਸਰ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ। ਇਸਨੂੰ ਵੱਖ ਰੱਖਣ ਨਾਲ ਏਜੰਟ ਨੂੰ ਅਸਪਸ਼ਟ ਨਤੀਜੇ ਸੁਲਝਾਉਣ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ, ਬਿਨਾਂ ਅਸਲ ਕਾਰਵਾਈ ਮੁੜ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇ।

ਇੱਕ ਫੇਲ ਰਨ ਹਰ ਰਿਕਵਰੀ ਹੱਦ ਪਾਰ ਕਰ ਸਕਦਾ ਹੈ

ਇੱਕ ਏਜੰਟ ਰਨ ਕੋਡ, ਡਾਟਾਬੇਸ ਰਿਕਾਰਡ ਅਤੇ ਬਾਹਰੀ ਸਿਸਟਮਾਂ ਨੂੰ ਸਮੇਂ ਦੇ ਵੱਖਰੇ ਬਿੰਦੂਆਂ ਉੱਤੇ ਛੱਡ ਸਕਦਾ ਹੈ। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਫੇਲਿਅਰ ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਵੇਖਣ ਨਾਲ ਉਹ ਖਾਲੀ ਥਾਂਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਆਮ ਰੋਲਬੈਕ ਕੰਟਰੋਲ ਲੁਕਾ ਦਿੰਦਾ ਹੈ।

ਮੰਨੋ ਏਜੰਟ ਮੈਂਬਰਸ਼ਿਪ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ, ਬਦਲਾਅ ਡਿਪਲੌਇ ਕਰਦਾ ਹੈ, ਗਾਹਕ ਸੂਚੀ ਇੰਪੋਰਟ ਕਰਦਾ ਹੈ, ਸਾਲਾਨਾ ਫੀਸਾਂ ਚਾਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਸੁਆਗਤ ਈਮੇਲਾਂ ਭੇਜਦਾ ਹੈ। ਕੰਮ ਇੱਕਸਾਰ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਘੱਟੋ-ਘੱਟ ਚਾਰ ਰਿਕਵਰੀ ਹੱਦਾਂ ਪਾਰ ਕਰਦਾ ਹੈ।

14:00 ਵਜੇ ਏਜੰਟ ਅਜਿਹਾ ਕੋਡ ਡਿਪਲੌਇ ਕਰਦਾ ਹੈ ਜੋ ਸਾਲਾਨਾ ਫੀਸ ਗਲਤ ਕਾਲਮ ਤੋਂ ਕੱਢਦਾ ਹੈ। 14:02 ਵਜੇ ਇਹ ਡਾਟਾਬੇਸ ਵਿੱਚ 40 ਭੁਗਤਾਨ intent ਅਤੇ ਈਮੇਲ ਡਰਾਫਟ ਲਿਖਦਾ ਹੈ। 14:03 ਵਜੇ ਵਰਕਰ ਕਈ ਭੁਗਤਾਨ capture ਕਰਦਾ ਹੈ। 14:04 ਵਜੇ ਮੇਲ ਪ੍ਰਦਾਤਾ ਗਲਤ ਫੀਸ ਵਾਲੇ ਸੁਆਗਤ ਸੁਨੇਹੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। 14:05 ਵਜੇ ਮਾਨੀਟਰਿੰਗ ਵਰਕਰ ਰੋਕ ਦਿੰਦੀ ਹੈ। ਕੁਝ ਭੁਗਤਾਨ ਕਾਲਾਂ ਪ੍ਰੋਸੈਸਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ ਟਾਈਮਆਉਟ ਹੋ ਗਈਆਂ, ਇਸ ਲਈ ਸਥਾਨਕ ਸਥਿਤੀ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਉਹ ਸਫਲ ਹੋਈਆਂ ਜਾਂ ਨਹੀਂ।

13:59 ਵਾਲਾ ਕੋਡ ਸਨੈਪਸ਼ਾਟ ਬਹਾਲ ਕਰਨ ਨਾਲ ਭਵਿੱਖ ਦੇ ਰਨ ਵਿੱਚ ਗਲਤ ਗਿਣਤੀ ਰੁਕ ਜਾਂਦੀ ਹੈ। Git ਕਮਿਟ revert ਕਰਨਾ ਸਰੋਤ ਸੁਧਾਰ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਪਰ ਇਸਦੀ ਵੀ ਇਹੋ ਹੱਦ ਹੈ।

ਡਾਟਾਬੇਸ ਨੂੰ 13:59 ਉੱਤੇ ਬਹਾਲ ਕਰਨ ਨਾਲ ਸਥਾਨਕ intent ਰਿਕਾਰਡ ਹਟ ਜਾਣਗੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਪ੍ਰਦਾਤਾ ਹਵਾਲੇ ਅਤੇ idempotency ਮੁੱਲ ਹਨ। ਇਸ ਨਾਲ ਬਾਹਰੀ ਬੇਮੇਲ ਹੋਰ ਮਾੜਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਬਿਹਤਰ ਡਾਟਾਬੇਸ ਕਾਰਵਾਈ ਲੌਜਿਕਲ ਸੁਧਾਰ ਹੈ: intent ਬਚਾਓ, ਅਨਿਸ਼ਚਿਤ ਕਾਰਵਾਈਆਂ ਨੂੰ ਮਿਲਾਨ ਲਈ ਮਾਰਕ ਕਰੋ ਅਤੇ ਪ੍ਰਦਾਤਾ ਹਾਲਤ ਨਾਲ ਮੇਲ ਤੋਂ ਬਾਅਦ ਹੀ ਕਤਾਰਾਂ ਠੀਕ ਕਰੋ।

ਫਿਰ response team ਨੂੰ ਅਸਰ ਦੀ ਸ਼੍ਰੇਣੀ ਅਨੁਸਾਰ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਹਰ ਅਨਿਸ਼ਚਿਤ ਭੁਗਤਾਨ ਨੂੰ ਉਸਦੀ ਸਥਿਰ ਓਪਰੇਸ਼ਨ ਪਛਾਣ ਨਾਲ ਪੁੱਛਦੀ ਹੈ। ਪੁਸ਼ਟੀ ਹੋਏ captures ਰਿਫੰਡ ਸਮੀਖਿਆ ਵੱਲ ਜਾਂਦੇ ਹਨ, ਫੇਲ ਕੋਸ਼ਿਸ਼ਾਂ ਬਿਨਾਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਬੰਦ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਨਾ ਸੁਲਝੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਬਲੌਕ ਰਹਿੰਦੀਆਂ ਹਨ। ਪਹੁੰਚੀਆਂ ਈਮੇਲਾਂ ਲਈ ਧਿਆਨ ਨਾਲ ਮਨਜ਼ੂਰ ਕੀਤਾ ਸੁਧਾਰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਜਿਹੜੇ ਕਤਾਰਬੱਧ ਸੁਨੇਹੇ ਹਾਲੇ ਪ੍ਰਦਾਤਾ ਤੱਕ ਨਹੀਂ ਗਏ, ਉਹ ਰੱਦ ਹੁੰਦੇ ਹਨ। ਹਰ ਮੁਆਵਜ਼ੇ ਨੂੰ ਅਸਲ ਕਾਰਵਾਈ ਨਾਲ ਜੁੜਿਆ ਨਵਾਂ intent ਮਿਲਦਾ ਹੈ।

ਇਹ ਮਿਸਾਲ ਇਹ ਵੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਆਟੋਮੈਟਿਕ ਮੁਆਵਜ਼ਾ ਖ਼ਤਰਨਾਕ ਕਿਉਂ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਸਿਸਟਮ ਹਰ ਸਥਾਨਕ payment_unknown ਰਿਕਾਰਡ ਦਾ ਤੁਰੰਤ ਰਿਫੰਡ ਕਰ ਦੇਵੇ, ਤਾਂ ਇਹ ਉਹਨਾਂ ਚਾਰਜਾਂ ਲਈ ਵੀ ਰਿਫੰਡ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਕਦੇ ਹੋਏ ਹੀ ਨਹੀਂ ਜਾਂ ਗਲਤ ਹਵਾਲੇ ਨਾਲ ਰਿਫੰਡ endpoint ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਡਾਟਾਬੇਸ ਰਿਕਵਰੀ ਤੋਂ ਬਾਅਦ ਹਰ ਗੁੰਮ ਈਮੇਲ ਫਿਰ ਭੇਜ ਦੇਵੇ, ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਨੂੰ ਡੁਪਲੀਕੇਟ ਮਿਲ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਸਥਾਨਕ ਅਤੇ ਪ੍ਰਦਾਤਾ ਹਾਲਤ ਅਸਹਿਮਤ ਹੋਣ, ਮੁਆਵਜ਼ੇ ਤੋਂ ਪਹਿਲਾਂ ਮਿਲਾਨ ਲਾਜ਼ਮੀ ਹੈ।

ਰਨ ਤਦ ਹੀ ਪੂਰਾ ਹੈ ਜਦੋਂ ਹਰ intent succeeded, confirmed_failed, compensated ਜਾਂ manual_exception ਵਰਗੀ ਅੰਤਿਮ ਹਾਲਤ ਤੱਕ ਪਹੁੰਚੇ। «ਐਪਲੀਕੇਸ਼ਨ ਰੋਲ ਬੈਕ ਹੋ ਗਈ» incident ਦਾ ਸਿਰਫ਼ ਪਹਿਲਾ ਹਿੱਸਾ ਦੱਸਦਾ ਹੈ।

ਰਿਕਵਰੀ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਸਬੂਤ ਬਚੇ ਰਹਿਣ

ਜਦੋਂ ਰੋਲਬੈਕ ਉਹ ਰਿਕਾਰਡ ਮਿਟਾ ਦੇਵੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ, ਤਾਂ ਰਿਕਵਰੀ ਕੰਟਰੋਲ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। Application state ਤੋਂ ਬਾਹਰ append-only effect ledger ਰੱਖੋ, ਜਿਸਨੂੰ ਆਮ ਸਨੈਪਸ਼ਾਟ ਜਾਂ ਬਹਾਲੀ ਬਦਲ ਨਾ ਸਕੇ, ਅਤੇ ਹਰ ਕਾਰਵਾਈ ਦੇ ਮਿਲਾਨ ਲਈ ਕਾਫ਼ੀ ਪ੍ਰਦਾਤਾ ਸਬੂਤ ਸੰਭਾਲੋ।

Ledger ਵਿੱਚ intent creation, argument digest, approval, execution lease, attempt, transport result, provider reference, ਦੇਖੀ ਹੋਈ provider state ਅਤੇ compensation links ਰਿਕਾਰਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਏਜੰਟਾਂ ਨੂੰ ਪੁਰਾਣੀਆਂ ਐਂਟਰੀਆਂ ਉੱਤੇ ਲਿਖਣ ਦੀ ਆਜ਼ਾਦੀ ਦੇਣ ਦੀ ਥਾਂ ਬਦਲਾਅ ਨੂੰ state transitions ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਸੁਧਾਰਾਂ ਨੂੰ ਇਤਿਹਾਸ ਸੋਧਣ ਦੀ ਥਾਂ events ਜੋੜਣੇ ਚਾਹੀਦੇ ਹਨ।

ਸਿਰਫ਼ ਸਪਸ਼ਟ ਗਲਤੀਆਂ ਨਹੀਂ, ਨਾ-ਸੁਲਝੀਆਂ ਹਾਲਤਾਂ ਦੀ ਵੀ ਨਿਗਰਾਨੀ ਕਰੋ। ਦਸ ਮਿੰਟ ਪਿਆ outcome_unknown ਸਾਫ਼ ਰੱਦ ਹੋਣ ਨਾਲੋਂ ਵੱਧ ਖ਼ਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਓਪਰੇਟਰ ਇਸਨੂੰ ਹੱਥੋਂ ਦੁਹਰਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ execution ਦੌਰਾਨ approval ਦੀ ਮਿਆਦ ਮੁੱਕੇ, idempotency ਮੁੱਲ ਵੱਖਰੇ argument digest ਨਾਲ ਦਿਸੇ ਜਾਂ compensation ਫੇਲ ਹੋਵੇ, ਤਦ ਵੀ alert ਕਰੋ।

ਜਾਣਬੁੱਝ ਕੇ ਅਸੁਖਾਵੇਂ failure points ਨਾਲ recovery drills ਚਲਾਓ। ਪ੍ਰਦਾਤਾ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪਰ ਸਥਾਨਕ success write ਤੋਂ ਪਹਿਲਾਂ ਵਰਕਰ ਬੰਦ ਕਰੋ। Effect ledger ਬਚਾਉਂਦੇ ਹੋਏ ਐਪਲੀਕੇਸ਼ਨ ਡਾਟਾ ਪੁਰਾਣੇ ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਬਹਾਲ ਕਰੋ। Planning ਅਤੇ execution ਦੇ ਵਿਚਕਾਰ approval ਦੀ ਮਿਆਦ ਖਤਮ ਕਰੋ। Observation API ਅਣਉਪਲਬਧ ਕਰੋ। ਡ੍ਰਿਲ ਤਦ ਪਾਸ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਿਸਟਮ ਰੁਕਦਾ ਹੈ, ਮਿਲਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਅਸਰ ਦੁਹਰਾਏ ਬਿਨਾਂ ਨਾ-ਸੁਲਝਿਆ ਫੈਸਲਾ ਦਿਖਾਉਂਦਾ ਹੈ।

Koder.ai ਵਰਤਦੇ ਸਮੇਂ, ਇਸਦੇ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਰਿਕਵਰੀ ਪਰਤ ਸਮਝੋ, ਫਿਰ ਡਾਟਾਬੇਸ ਇਤਿਹਾਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵੱਲੋਂ ਚਲਾਈ ਜਾ ਸਕਣ ਵਾਲੀ ਹਰ ਬਾਹਰੀ ਕਾਰਵਾਈ ਲਈ ਵੱਖਰੇ ਕੰਟਰੋਲ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਸਰੋਤ ਐਕਸਪੋਰਟ, ਡਿਪਲੌਇਮੈਂਟ ਕੰਟਰੋਲ ਅਤੇ ਰੋਲਬੈਕ ਸਾਫਟਵੇਅਰ ਬਹਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਟੂਲ ਕਾਂਟ੍ਰੈਕਟ ਹਾਲੇ ਵੀ ਮਨਜ਼ੂਰੀਆਂ ਅਤੇ ਮੁਆਵਜ਼ੇ ਦੇ ਮਾਲਕ ਹਨ।

ਰੋਲਬੈਕ ਬਟਨ ਉੱਤੇ ਉਸਦੀ ਹੱਦ ਲਿਖੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਕੋਡ, ਕੌਂਫਿਗਰੇਸ਼ਨ, ਪ੍ਰਬੰਧਿਤ ਡਾਟਾ ਜਾਂ ਬਾਹਰੀ ਅਸਰ। ਜੇ ਇੰਟਰਫੇਸ ਇਸ ਵਾਕ ਨੂੰ ਸਪਸ਼ਟ ਨਹੀਂ ਬਣਾ ਸਕਦਾ, ਇਸਨੂੰ ਰੋਲਬੈਕ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਮਾਨਦਾਰ ਕੰਟਰੋਲ ਘੱਟ ਜਾਦੂਈ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਰਾਤ ਦੇ 2 ਵਜੇ incident team ਨੂੰ ਇਹੀ ਇੱਕ ਚੀਜ਼ ਚਾਹੀਦੀ ਹੈ: ਕੀ ਬਦਲਿਆ, ਕੀ ਬਾਹਰ ਨਿਕਲ ਗਿਆ ਅਤੇ ਅਗਲੀ ਕਿਹੜੀ ਕਾਰਵਾਈ ਸੁਰੱਖਿਅਤ ਹੈ, ਇਸਦਾ ਭਰੋਸੇਯੋਗ ਵੇਰਵਾ।