ਜਦੋਂ ਵੀ ਕੋਈ ਯੂਜ਼ਰ ਸੈਂਡ ਬਟਨ ਨੂੰ ਲਗਾਤਾਰ ਦਬਾਉਂਦਾ ਸੀ, ਤਾਂ ਬੋਟ ਇੱਕੋ ਜਵਾਬ ਦੋ ਜਾਂ ਤਿੰਨ ਵਾਰ ਦੇਣ ਲੱਗ ਪੈਂਦਾ ਸੀ। ਇਹ ਦੁਹਰਾਓ ਸਿਰਫ਼ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ ਜੋ AI ਦੇ ਸੋਚਣ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਸੁਨੇਹੇ ਭੇਜਣ ਲਈ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰਦੇ ਸਨ, ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਪੈਟਰਨ ਬਹੁਤ ਘੱਟ ਸੀ, ਇਸ ਲਈ ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲੁਕਿਆ ਰਿਹਾ। ਇੱਕ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਡਾਟਾਬੇਸ ਲੌਕ ਦਾ ਖੁੱਲ੍ਹ ਜਾਣਾ – ਜੋ ਲਏ ਜਾਣ ਤੋਂ ਕੁਝ ਮਿਲੀਸੈਕਿੰਡ ਬਾਅਦ ਹੀ ਰਿਲੀਜ਼ ਹੋ ਗਿਆ ਸੀ – ਗੱਲਬਾਤ ਨੂੰ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਦੇ ਛੱਡ ਗਿਆ, ਜਿਸ ਨਾਲ ਕਈ ਪ੍ਰੋਸੈਸਾਂ ਨੂੰ ਇੱਕੋ ਪ੍ਰੋਂਪਟ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲ ਗਈ।
ਲੌਕ ਕਿਉਂ ਫੇਲ ਹੋ ਗਿਆ
ਕੋਡ ਨੇ ਇੱਕ ਸਿੰਗਲ ਡਾਟਾਬੇਸ ਕਾਲ ਵਿੱਚ ਲੌਕ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਅਤੇ ਫਿਰ ਤੁਰੰਤ ਕੰਟਰੋਲ ਰਿਕੁਐਸਟ ਹੈਂਡਲਰ ਨੂੰ ਵਾਪਸ ਦੇ ਦਿੱਤਾ। ਲੌਕ ਦੀ ਉਮਰ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਸੀ, ਜੋ ਕਿ AI ਮਾਡਲ ਨੂੰ ਜਵਾਬ ਤਿਆਰ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਸਮੇਂ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਘੱਟ ਸੀ। ਜਦੋਂ ਤੱਕ ਮਾਡਲ ਨੇ ਕੰਮ ਸ਼ੁਰੂ ਕੀਤਾ, ਲੌਕ ਪਹਿਲਾਂ ਹੀ ਖਤਮ ਹੋ ਚੁੱਕਾ ਸੀ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੇ ਦੂਜੀ ਰਿਕੁਐਸਟ ਨੂੰ ਉਹੀ ਗੱਲਬਾਤ ਰਿਕਾਰਡ ਲੈਣ ਅਤੇ ਇੱਕ ਹੋਰ ਜਵਾਬ ਜਾਰੀ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਿਆ।
ਦੋ ਲੱਛਣ ਸਾਹਮਣੇ ਆਏ:
- ਇੱਕੋ ਜਿਹੇ ਜਵਾਬ ਲਗਾਤਾਰ ਭੇਜੇ ਗਏ।
- ਇੱਕੋ ਸਵਾਲ ਲਈ ਥੋੜ੍ਹੇ ਬਹੁਤ ਵੱਖਰੇ ਸ਼ਬਦਾਂ ਵਾਲੇ ਜਵਾਬ ਦਿਖਾਈ ਦਿੱਤੇ, ਕਿਉਂਕਿ ਹਰੇਕ ਪ੍ਰੋਸੈਸ ਨੇ ਇੱਕੋ ਯੂਜ਼ਰ ਇਨਪੁਟ ਤੋਂ ਆਪਣਾ ਪ੍ਰੋਂਪਟ ਤਿਆਰ ਕੀਤਾ ਸੀ।
ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰ ਸੁਨੇਹਿਆਂ ਦੇ ਵਿਚਕਾਰ ਰੁਕਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਬੱਗ (bug) ਨਜ਼ਰ ਨਹੀਂ ਆਇਆ। ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰਨ ਵਾਲੇ ਲੋਕ ਹੀ ਰੇਸ ਕੰਡੀਸ਼ਨ (race condition) ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਸਨ, ਅਤੇ ਅਜਿਹੇ ਮਾਮਲੇ ਬਹੁਤ ਘੱਟ ਸਨ।
ਅਧੂਰਾ ਹੱਲ ਜੋ ਕੰਮ ਨਹੀਂ ਆਇਆ
ਪਹਿਲਾ ਹੱਲ ਸੁਨੇਹਾ ਆਉਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਦੇਰੀ (delay) ਜੋੜਨਾ ਸੀ, ਤਾਂ ਜੋ ਤੇਜ਼ ਇਨਪੁਟ ਨੂੰ “debounce” ਕੀਤਾ ਜਾ ਸਕੇ। ਇਸ ਨਾਲ ਉਦੋਂ ਮਦਦ ਮਿਲੀ ਜਦੋਂ ਦੋ ਸੁਨੇਹੇ ਲਗਾਤਾਰ ਆਏ, ਪਰ ਜੇਕਰ AI ਅਜੇ ਵੀ ਟੈਕਸਟ ਤਿਆਰ ਕਰ ਰਿਹਾ ਹੋਵੇ ਅਤੇ ਤੀਜਾ ਸੁਨੇਹਾ ਆ ਜਾਵੇ, ਤਾਂ ਇਹ ਫੇਲ ਹੋ ਗਿਆ।
ਦੂਜੀ ਸਮੱਸਿਆ ਉਦੋਂ ਸਾਹਮਣੇ ਆਈ ਜਦੋਂ ਟਾਈਮਰ ਅਤੇ ਗੱਲਬਾਤ ਦਾ ਡਾਟਾ ਇੱਕੋ ਸਟੋਰੇਜ ਬੱਕੇਟ (storage bucket) ਵਿੱਚ ਸੀ। ਜਦੋਂ ਬੋਟ ਨੇ ਰਿਕੁਐਸਟ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਖਤਮ ਕੀਤੀ, ਤਾਂ ਉਸਨੇ ਟਾਈਮਰ ਰਿਕਾਰਡ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਉਸਦਾ ਆਪਣਾ ਕਾਊਂਟਡਾਊਨ ਹੀ ਡਿਲੀਟ ਹੋ ਗਿਆ। ਸਿਸਟਮ ਇਹ ਰੱਖਣਾ ਭੁੱਲ ਗਿਆ ਕਿ ਕਿਹੜੇ ਸੁਨੇਹਿਆਂ ਦੇ ਜਵਾਬ ਦਿੱਤੇ ਜਾ ਚੁੱਕੇ ਹਨ, ਜਿਸ ਨਾਲ ਹੋਰ ਦੁਹਰਾਓ ਦੀ ਸੰਭਾਵਨਾ ਵਧ ਗਈ।
ਇੱਕ ਭਰੋਸੇਮੰਦ ਸੁਰੱਖਿਆ ਬਣਾਉਣਾ: ਵਰਜ਼ਨ ਕਾਊਂਟਰ, ਵੱਖਰੇ ਟਾਈਮਰ, ਅਤੇ ਇੱਕ ਲੀਜ਼
ਟੀਮ ਨੇ ਤਿੰਨ ਮੁੱਖ ਸਹਾਰਿਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਫਲੋਅ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕੀਤਾ:
- ਵਰਜ਼ਨ ਕਾਊਂਟਰ (Version counter) – ਹਰੇਕ ਆਉਣ ਵਾਲਾ ਸੁਨੇਹਾ ਗੱਲਬਾਤ ਦੇ ਨਾਲ ਸਟੋਰ ਕੀਤੇ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਕਾਊਂਟਰ ਸਿਸਟਮ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪਿਛਲੇ ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਕਿੰਨੇ ਸੁਨੇਹੇ ਆ ਚੁੱਕੇ ਹਨ, ਜਿਸ ਨਾਲ ਜਵਾਬ ਤਿਆਰ ਹੋਣ ਦੌਰਾਨ ਨਵੇਂ ਇਨਪੁਟ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
- ਸਪੈਸ਼ਲ ਡੀਬਾਊਂਸ ਵਿੰਡੋ (Dedicated debounce window) – ਟਾਈਮਰ ਹੁਣ ਇੱਕ ਵੱਖਰੇ ਸਟੋਰੇਜ ਖੇਤਰ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਜੋ ਗੱਲਬਾਤ ਦੇ ਡਾਟਾ ਤੋਂ ਵੱਖਰੇ ਹਨ। ਡੀਬਾਊਂਸ ਦੀ ਮਿਆਦ 'ਤੇ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਲਗਾਉਣ ਨਾਲ ਯੂਜ਼ਰ ਨੂੰ ਬੋਟ ਨੂੰ ਅਨੰਤ ਕਾਲੇ ਲਈ ਰੋਕਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
- ਸੈਸ਼ਨ ਲੀਜ਼ (Session lease) – ਅਸਲ ਲੌਕ ਨੂੰ ਇੱਕ ਲੀਜ਼ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਪੱਸ਼ਟ ਐਕਸਪਾਇਰੀ ਟਾਈਮਸਟੈਂਪ ਹੁੰਦਾ ਹੈ। ਲੀਜ਼ ਨੂੰ compare-and-swap (CAS) ਆਪਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲੇਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਪ੍ਰੋਸੈਸ ਮੌਜੂਦਾ ਲੀਜ਼ ਵੈਲਯੂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਅਤੇ ਨਵੀਂ ਵੈਲਯੂ ਉਦੋਂ ਹੀ ਲਿਖਦਾ ਹੈ ਜੇਕਰ ਪੁਰਾਣੀ ਵੈਲਯੂ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਗੱਲਬਾਤ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਪ੍ਰੋਸੈਸ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੀਜ਼ ਆਪਣੇ ਆਪ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਅਗਲੇ ਹੈਂਡਲਰ ਲਈ ਗੱਲਬਾਤ ਖੁੱਲ੍ਹ ਜਾਂਦੀ ਹੈ।
ਨਵਾਂ ਪਾਈਪਲਾਈਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
- ਸੁਨੇਹਾ ਆਉਣਾ (Message arrival) – ਸਿਸਟਮ ਵਰਜ਼ਨ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਡੀਬਾਊਂਸ ਟਾਈਮਰ ਨੂੰ (ਰੀ)ਸੈੱਟ ਕਰਦਾ ਹੈ। ਇਹ AI ਨੂੰ ਸ਼ੁਰੂ ਕੀਤੇ ਬਿਨਾਂ ਤੁਰੰਤ ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ।
- ਟਾਈਮਰ ਦੀ ਸਮਾਪਤੀ (Timer expiration) –