ਕ੍ਰੌਨ-ਡਰਾਈਵਨ (cron-driven) ਈਮੇਲ ਚੈੱਕ ਕਿਉਂ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ
ਕਾਗਜ਼ 'ਤੇ ਹਰ ਕੁਝ ਘੰਟਿਆਂ ਬਾਅਦ ਇੱਕ ਜੌਬ (job) ਚਲਾਉਣਾ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਦੀ ਅਸਲੀਅਤ ਕਾਫੀ ਉਲਝਣ ਭਰੀ ਹੁੰਦੀ ਹੈ। ਪਿਛਲੀ ਰਨ (run) ਕੁਝ ਵਾਧੂ ਸੁਨੇਹੇ ਛੱਡ ਸਕਦੀ ਹੈ; ਰੀਟ੍ਰਾਈਜ਼ (retries) ਇਕੱਠੇ ਹੋ ਸਕਦੇ ਹਨ; ਇੱਕ ਹੌਲੀ ਵਰਕਰ ਉਹ ਸੁਨੇਹਾ ਚੁੱਕ ਸਕਦਾ ਹੈ ਜੋ ਪੰਦਰਾਂ ਮਿੰਟ ਪਹਿਲਾਂ ਆਇਆ ਸੀ। ਉਹ ਬਚੇ ਹੋਏ ਸੁਨੇਹੇ ਉਸ ਨਾਦਾਨਾਨਾ “ਤਾਜ਼ਾ ਈਮੇਲ ਜਿੱਤਦੀ ਹੈ” (latest email wins) ਵਾਲੇ ਨਿਯਮ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ ਜਿਸ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰਿਪਟਾਂ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
ਲੋਕਲ ਟੈਸਟ ਇਸ ਲਈ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਸਾਫ਼ ਇਨਬਾਕਸ ਅਤੇ ਅਨੁਮਾਨਿਤ ਸਮੇਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਉਹੀ ਕੋਡ ਗਲਤ ਸੁਨੇਹਾ ਚੁੱਕ ਸਕਦਾ ਹੈ, ਚੁੱਪਚਾਪ ਕਿਸੇ ਅਲਰਟ ਨੂੰ ਡ੍ਰੌਪ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜ ਸਕਦਾ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ 임ਤਿਆਰੀ (arbitrary) ਦੇਰੀ ਨਾਲ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਦੇਰੀ ਸਿਰਫ ਰੇਸ ਕੰਡੀਸ਼ਨ (race condition) ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ ਅਤੇ ਜਲਦੀ ਹੀ ਵਧੇਰੇ ਲੋਡ ਜਾਂ ਈਮੇਲ ਲੇਟੈਂਸੀ (latency) ਵਿੱਚ ਬਦਲਾਅ ਕਾਰਨ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਲੀਜ਼ (lease) ਦਾ ਸੰਕਲਪ: ਇੱਕ ਇਨਬਾਕਸ ਨੂੰ ਇੱਕ ਵਰਤ ਕੇ ਸੁੱਟਣਯੋਗ (disposable) ਸੰਪਤੀ ਵਿੱਚ ਬਦਲਣਾ
ਇੱਕ ਇਨਬਾਕਸ ਲੀਜ਼ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਇਕਰਾਰਨਾਮਾ ਹੈ ਜਿਸਦਾ ਹਰ ਕ੍ਰੌਨ ਰਨ (cron run) ਨੂੰ ਪਾਲਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
- Exclusive ownership – ਇੱਕ ਰਨ ਨੂੰ ਇੱਕ ਇਨਬਾਕਸ (ਜਾਂ ਇਸ ਦੇ ਅੰਦਰ ਇੱਕ ਵਿਲੱਖਣ ਨਾਮਸਪੇਸ) ਮਿਲਦਾ ਹੈ।
- Time-bounded – ਲੀਜ਼ ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ ਅਤੇ ਖਤਮ ਹੋਣ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ।
- Label verification – ਹਰ ਉਮੀਦਵਾਰ ਈਮੇਲ ਵਿੱਚ ਇੱਕ ਲੇਬਲ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਜੌਬ ਜਾਂਚ ਕਰਦੀ ਹੈ।
- Stale-message guard – ਜੌਬ ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਈਮੇਲ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੀ ਹੈ ਜੋ ਉਸਦੀ ਲੀਜ਼ ਵਿੰਡੋ (lease window) ਤੋਂ ਬਾਹਰ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਵਿਸ਼ਾ (subject) ਮੈਚ ਹੀ ਕਿਉਂ ਨਾ ਕਰਦਾ ਹੋਵੇ।
“ਕੀ ਕੋਈ ਈਮੇਲ ਆਈ ਹੈ?” ਪੁੱਛਣ ਦੀ ਬਜਾਏ, ਜੌਬ ਹੁਣ ਪੁੱਛਦੀ ਹੈ “ਕੀ ਮੇਰੀ ਈਮੇਲ ਮੇਰੀ ਲੀਜ਼ ਵਿੰਡੋ ਦੌਰਾਨ ਆਈ ਹੈ?”। ਇਹ ਬਦਲਾਅ ਕੋਡ ਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਕਿ ਸੁਨੇਹਾ ਮੌਜੂਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (execution) ਨਾਲ ਸਬੰਧਤ ਹੈ, ਜਿਸ ਨਾਲ ਕ੍ਰੌਨ ਰਨਾਂ ਵਿਚਕਾਰ ਹੋਣ ਵਾਲੀ ਗਲਤੀ (cross-run contamination) ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਆਮ ਚਾਰ-ਘੰਟੇ ਦੇ ਕ੍ਰੌਨ (cron) ਵਿੱਚ ਇਸ ਪੈਟਰਨ ਨੂੰ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਵੇ
- Create a lease ID ਰਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਚੁਣੇ ਹੋਏ ਇਨਬਾਕਸ ID ਦੇ ਨਾਲ ਸਟੋਰ ਕਰੋ।
- Apply a strict filter ਪੋਲਿੰਗ (polling) ਕਰਦੇ ਸਮੇਂ: ਲੀਜ਼ ਲੇਬਲ, ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਵਿਲੱਖਣਤਾ (recipient uniqueness), ਖਾਸ ਵਿਸ਼ਾ (subject), ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਪ੍ਰਾਪਤ ਹੋਣ ਦੇ ਟਾਈਮਸਟੈਂਪ (timestamp) ਦੇ ਅਧਾਰ 'ਤੇ ਮੈਚ ਕਰੋ।
- Log the lease metadata – ਲੀਜ਼ ID, ਇਨਬਾਕਸ ID, ਅਤੇ ਕਿਸੇ ਵੀ ਮੈਚ ਹੋਏ ਸੁਨੇਹੇ ਦਾ ਸਹੀ ਪ੍ਰਾਪਤ ਹੋਣ ਦਾ ਸਮਾਂ।
ਲੌਗਸ ਵਿੱਚ ਇਹ ਤਿੰਨ ਚੀਜ਼ਾਂ ਹੋਣ ਨਾਲ, ਕੋਈ ਵੀ ਅਸਫਲਤਾ ਇੱਕ ਗੁੰਮ ਹੋਈ ਲੀਜ਼, ਗਲਤ ਰੂਟ ਕੀਤੇ ਇਨਬਾਕਸ, ਜਾਂ ਵਿੰਡੋ ਤੋਂ ਬਾਹਰ ਦੀ ਈਮੇਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਅਸਪਸ਼ਟ “ਕੋਈ ਈਮੇਲ ਨਹੀਂ ਮਿਲੀ” ਸੁਨੇਹਾ।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਅਜੇ ਵੀ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਖਰਾਬ ਕਰਦੀਆਂ ਹਨ
- Reusing inbox names for tidy dashboards – ਮਨੁੱਖੀ ਪੜ੍ਹਨਯੋਗ ਨਾਮ ਵਧੀਆ ਲੱਗਦੇ ਹਨ, ਪਰ ਉਹ ਸਾਂਝੀ ਸਟੇਟ (shared state) ਨੂੰ ਦੁਬਾਰਾ ਲਿਆਉਂਦੇ ਹਨ।
- Scattering polling rules across files – ਅਸੰਗਤ “ਤਾਜ਼ਗੀ” (freshness) ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਪੁਰਾਣੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਅੰਦਰ ਆਉਣ ਦਿੰਦੀਆਂ ਹਨ।
- Skipping lease-ID logging – ਉਸ ਪਛਾਣਕਰਤਾ (identifier) ਤੋਂ ਬਿਨਾਂ ਡੀਬੱਗਿੰਗ ਅੰਦਾਜ਼ੇ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਉਹ ਸਥਿਤੀ ਹੈ ਜੋ ਅਸਥਿਰ ਚੈੱਕਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਦੀ ਹੈ।
ਇਨ੍ਹਾਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ ਸਿਸਟਮ ਨੂੰ ਸਹੀ ਅਤੇ ਲੌਗਸ ਨੂੰ ਉਪਯੋਗੀ ਰੱਖਦਾ ਹੈ।
ਜਦੋਂ ਆਇਸੋਲੇਸ਼ਨ (isolation) ਸੰਭਵ ਨਾ ਹੋਵੇ, ਤਾਂ ਫਿਲਟਰਾਂ ਨੂੰ ਸਖ਼ਤ ਕਰੋ
ਜੇਕਰ ਹਰ ਰਨ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਇਨਬਾਕਸ ਬਣਾਉਣਾ ਅਵਿਵਹਾਰਕ ਹੈ, ਤਾਂ ਸਖ਼ਤ ਮਾਪਦੰਡਾਂ ਨਾਲ ਇਸਦੀ ਭਰਪਾਈ ਕਰੋ:
- Receive time window – ਲੀਜ਼ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪੁਰਾਣੀ ਕਿਸੇ ਵੀ ਈਮੇਲ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ।
- Recipient uniqueness – ਜੇਕਰ ਪ੍ਰੋਵਾਈਡਰ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਪ੍ਰਤੀ-ਰਨ (per-run) ਪਤਾ ਜਾਂ ਵਿਲੱਖਣ ਐਲੀਅਸ (alias) ਦੀ ਵਰਤੋਂ ਕਰੋ।
- Subject fingerprint – ਵਿਸ਼ਾ ਲਾਈਨ ਵਿੱਚ ਰਨ-ਵਿਸ਼ੇਸ਼ ਟੋਕਨ (run-specific token) ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ।
ਲੀਜ਼ ਦੀ ਅੰਸ਼ਕ ਲਾਗੂ ਕਰਨ ਨਾਲ ਵੀ ਸਟੇਟ ਡ੍ਰਿਫਟ (state drift) ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਮਹਿੰਗਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਾਫੀ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਵਿਰੋਧੀ ਨੁਕਤਾ: “ਸਿਰਫ ਦੇਰੀ ਜੋੜ ਦਿਓ” ਕਿਉਂ ਅਜੇ ਵੀ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ
ਕੁਝ ਟੀਮਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਰਨਾਂ ਦੇ ਵਿਚਕਾਰ ਕੁਝ ਸਕਿੰਟਾਂ ਦੀ ਸਲੀਪ (sleep) ਕਾਫੀ ਹੈ। ਦੇਰੀ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਈਮੇਲ ਲੇਟੈਂਸੀ ਬਫਰ ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ, ਪਰ ਪ੍ਰੋਵਾਈਡਰ ਲੇਟੈਂਸੀ ਵਿੱਚ ਕੋਈ ਵੀ ਵਾਧਾ, ਅਸਥਾਈ ਬੈਕਲੌਗ, ਜਾਂ ਸਕੈਲਿੰਗ ਈਵੈਂਟ ਤੁਰੰਤ ਇਸ ਅਨੁਮਾਨ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ।
ਸਿੱਖਿਆ (Takeaway)
ਹਰ ਰਨ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਇਨਬਾਕਸ (ਜਾਂ ਨਾਮਸਪੇਸ) ਨਾਲ ਜੋੜ ਕੇ, ਉਮੀਦਵਾਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਲੇਬਲ ਕਰਕੇ, ਅਤੇ ਲੀਜ਼ ਪਛਾਣਕਰਤਾਵਾਂ (lease identifiers) ਨੂੰ ਲੌਗ ਕਰਕੇ, ਤੁਸੀਂ ਕ੍ਰੌਨ ਰਨਾਂ ਵਿਚਕਾਰ ਹੋਣ ਵਾਲੀ ਗਲਤੀ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹੋ, ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਦੇਖਣਯੋਗ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਉਹ ਭਰੋਸੇਯੋਗਤਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਜਿਸਦੀ ਸ਼ਡਿਊਲਡ ਅਲਰਟਾਂ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ।