ਪਬਲਿਸ਼ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕਰੈਸ਼ ਹੋਣ ਵਾਲੀਆਂ ਐਪਾਂ ਨੂੰ ਫੜਨਾ
25 ਸਤੰਬਰ ਨੂੰ, ਤਿੰਨ ਪਬਲਿਸ਼ਾਂ ਨੂੰ ਸਫ਼ਲ ਮੰਨਿਆ ਗਿਆ, ਜਦਕਿ ਹਰ ਬੂਟ 'ਤੇ ਐਪ ਦੀ API ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਕਰੈਸ਼ ਹੋ ਰਹੀ ਸੀ। ਕਿਉਂਕਿ ਉਹ "ਸਫ਼ਲ" ਸਨ, ਕੋਈ ਰੋਲਬੈਕ ਨਹੀਂ ਚੱਲਿਆ; ਇੱਕ ਪਿਛੋਕੜ ਜਾਂਚ ਨੇ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਉਹਨਾਂ ਨੂੰ ਫ਼ੇਲ੍ਹ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਪੂਰੀ ਸਾਈਟ 404 'ਤੇ ਚਲੀ ਗਈ। ਹੈਲਥ ਚੈੱਕ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਦੀ ਇਵੈਂਟ ਸੂਚੀ ਵਿੱਚ ਕਰੈਸ਼ ਗਿਣ ਰਿਹਾ ਸੀ, ਜਿਸ ਵਿੱਚ ਹਰ ਮਸ਼ੀਨ ਲਈ ਸਿਰਫ਼ ਆਖਰੀ ਪੰਜ ਇਵੈਂਟ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਕਰੈਸ਼ ਲੂਪ ਉਸਨੂੰ ਭਰੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਗਿਣਤੀ ਕਦੇ ਵਧਦੀ ਨਹੀਂ। ਹੁਣ ਇਹ ਤਾਜ਼ਾ ਕਰੈਸ਼ ਦਾ ਸਮਾਂ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਰੈਸ਼ ਲੂਪ ਵਾਲਾ ਪਬਲਿਸ਼ ਫ਼ੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪਿਛਲਾ ਵਰਜਨ ਬਹਾਲ ਹੁੰਦਾ ਹੈ।
ਪਬਲਿਸ਼ ਕਿਸ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ
ਜਦੋਂ ਤੁਸੀਂ Mythex 'ਤੇ ਬੈਕਐਂਡ ਵਾਲੀ ਐਪ ਪਬਲਿਸ਼ ਕਰਦੇ ਹੋ, ਨਵਾਂ ਵਰਜਨ ਸਾਡੇ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰੋਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਹੈਲਥ ਚੈੱਕ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਪਬਲਿਸ਼ ਲਾਈਵ ਹੋਇਆ ਜਾਂ ਫ਼ੇਲ੍ਹ। ਜੇ ਫ਼ੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਰੋਲਬੈਕ ਪਿਛਲਾ ਵਰਜਨ ਵਾਪਸ ਰੱਖਦਾ ਹੈ।
ਔਖੀ ਗੱਲ ਇਹ ਹੈ ਕਿ "ਸ਼ੁਰੂ ਹੋਇਆ" ਅਤੇ "ਸੇਵਾ ਦੇ ਰਿਹਾ" ਇੱਕੋ ਚੀਜ਼ ਨਹੀਂ। ਪਲੇਟਫਾਰਮ ਮਸ਼ੀਨ ਨੂੰ ਉਦੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਦੱਸਦਾ ਹੈ ਜਦੋਂ ਉਹ ਉੱਪਰ ਆਉਂਦੀ ਹੈ। ਇੱਕ ਐਪ ਜੋ ਬੂਟ ਤੋਂ ਇੱਕ ਸਕਿੰਟ ਬਾਅਦ ਕਰੈਸ਼ ਹੁੰਦੀ ਹੈ, ਤੁਰੰਤ ਮੁੜ ਚਾਲੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਪਲ ਬਾਅਦ ਫਿਰ ਸ਼ੁਰੂ ਹੋਈ ਦਿਖਦੀ ਹੈ। ਇਸ ਲਈ ਹੈਲਥ ਚੈੱਕ ਕਈ ਪਰਤਾਂ ਵਿੱਚ ਵਧਿਆ ਸੀ:
- ਦੋ ਵਾਰ ਦੇਖੋ। ਮਸ਼ੀਨ ਸ਼ੁਰੂ ਹੋਈ ਦਿਸਣ ਤੋਂ ਬਾਅਦ, ਥੋੜ੍ਹੀ ਦੇਰ ਰੁਕ ਕੇ ਫਿਰ ਦੇਖੋ। ਬੂਟ 'ਤੇ ਕਰੈਸ਼ ਅਕਸਰ ਦੂਜੀ ਝਾਤ 'ਤੇ ਫ਼ੇਲ੍ਹ ਦਿਖਦਾ ਹੈ।
- ਕਰੈਸ਼ ਲੂਪ ਲੱਭੋ। ਜੇ ਪਲੇਟਫਾਰਮ ਦੱਸੇ ਕਿ ਮਸ਼ੀਨ ਵਾਰ-ਵਾਰ ਕਰੈਸ਼ ਹੋ ਰਹੀ ਸੀ ਅਤੇ ਉਸਨੇ ਰੀਸਟਾਰਟ ਕਰਨਾ ਛੱਡ ਦਿੱਤਾ, ਤਾਂ ਫ਼ੇਲ੍ਹ ਕਰੋ।
- ਪਬਲਿਸ਼ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦੇ ਕਰੈਸ਼ ਗਿਣੋ। ਦੋ "ਸ਼ੁਰੂ ਹੋਇਆ" ਦਿਸਣ ਵਿਚਕਾਰ ਰੀਸਟਾਰਟ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਜੇ ਪਬਲਿਸ਼ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੋਈ ਵੀ ਕਰੈਸ਼ ਹੋਇਆ ਹੋਵੇ, ਤਾਂ ਤੀਜੀ ਵਾਰ ਦੇਖੋ; ਜੇ ਪਿਛਲੀ ਝਾਤ ਨਾਲੋਂ ਵੱਧ ਕਰੈਸ਼ ਹਨ, ਤਾਂ ਐਪ ਚਾਲੂ ਨਹੀਂ ਰਹਿ ਰਹੀ।
ਤੀਜੀ ਜਾਂਚ ਉਹ ਸੀ ਜੋ ਇਸ ਵਾਰ ਫ਼ੇਲ੍ਹ ਹੋਈ।
ਗਿਣਤੀ ਕਿਉਂ ਸਥਿਰ ਰਹੀ
ਕਰੈਸ਼ ਦੀ ਜਾਣਕਾਰੀ ਹਰ ਮਸ਼ੀਨ ਦੀ ਇਵੈਂਟ ਸੂਚੀ ਤੋਂ ਆਉਂਦੀ ਹੈ: ਸ਼ੁਰੂਆਤਾਂ, ਬੰਦ ਹੋਣੇ, ਰੀਸਟਾਰਟ। ਪਲੇਟਫਾਰਮ ਹਰ ਮਸ਼ੀਨ ਲਈ ਸਿਰਫ਼ ਆਖਰੀ ਪੰਜ ਇਵੈਂਟ ਰੱਖਦਾ ਹੈ।
ਇੱਕ ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜੋ ਬੂਟ ਤੋਂ ਢਾਈ ਸਕਿੰਟ ਬਾਅਦ ਕਰੈਸ਼ ਹੁੰਦੀ ਹੈ, ਜਿਵੇਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਰਦੀ ਸੀ। ਹਰ ਚੱਕਰ ਇੱਕ ਕਰੈਸ਼ ਅਤੇ ਇੱਕ ਸ਼ੁਰੂਆਤ ਜੋੜਦਾ ਹੈ। ਕੁਝ ਚੱਕਰਾਂ ਬਾਅਦ ਸੂਚੀ ਭਰ ਜਾਂਦੀ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਹਰ ਨਵਾਂ ਇਵੈਂਟ ਇੱਕ ਪੁਰਾਣਾ ਬਾਹਰ ਧੱਕਦਾ ਹੈ। ਸੂਚੀ ਅੱਗੇ ਖਿਸਕਦੀ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਲਗਭਗ ਇੱਕੋ ਮਿਸ਼ਰਣ ਰੱਖਦੀ ਹੈ: ਕੁਝ ਕਰੈਸ਼, ਕੁਝ ਸ਼ੁਰੂਆਤਾਂ।
ਇਸ ਲਈ "ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕਿੰਨੇ ਕਰੈਸ਼ ਹੋਏ" ਹਰ ਝਾਤ 'ਤੇ ਇੱਕੋ ਗਿਣਤੀ ਦਿੰਦਾ ਸੀ। ਦੂਜੀ ਝਾਤ ਨੇ, ਮੰਨ ਲਓ, ਦੋ ਕਰੈਸ਼ ਦੇਖੇ। ਤੀਜੀ ਝਾਤ ਨੇ ਵੀ ਦੋ ਦੇਖੇ, ਭਾਵੇਂ ਵੱਖਰੇ ਕਰੈਸ਼। ਜਾਂਚ ਨੇ ਸਿੱਟਾ ਕੱਢਿਆ ਕਿ ਕਰੈਸ਼ ਹੋਣਾ ਰੁਕ ਗਿਆ ਹੈ, ਅਤੇ ਪਬਲਿਸ਼ ਨੂੰ ਪਾਸ ਕਰ ਦਿੱਤਾ।
ਇਹ ਤਿੰਨ ਵਾਰ 25 ਸਤੰਬਰ ਨੂੰ, ਦੋ ਐਪਾਂ 'ਤੇ ਹੋਇਆ। ਹਰ ਵਾਰ:
- ਪਬਲਿਸ਼ ਲਾਈਵ ਦਿਖਾਇਆ ਗਿਆ,
- ਕੋਈ ਰੋਲਬੈਕ ਨਹੀਂ ਚੱਲਿਆ, ਕਿਉਂਕਿ ਕੁਝ ਫ਼ੇਲ੍ਹ ਨਹੀਂ ਹੋਇਆ ਸੀ,
- ਸਾਡੇ ਰੀਕਨਸਿਲਰ, ਇੱਕ ਪਿਛੋਕੜ ਜੌਬ ਜੋ ਡਿਪਲੌਇਮੈਂਟਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਜਾਂਚਦੀ ਹੈ, ਨੇ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਡਿਪਲੌਇਮੈਂਟ ਫ਼ੇਲ੍ਹ ਕੀਤੀ,
- ਅਤੇ ਪੂਰੀ ਸਾਈਟ 404 ਦਿੰਦੀ ਰਹੀ।
ਇੱਕ ਪਬਲਿਸ਼ ਜੋ ਸਮੇਂ 'ਤੇ ਫ਼ੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਉਹ ਬਚ ਸਕਦਾ ਹੈ: ਰੋਲਬੈਕ ਪਿਛਲਾ ਵਰਜਨ ਬਹਾਲ ਕਰਦਾ ਹੈ। ਪਰ ਜੋ ਪਬਲਿਸ਼ ਕੁਝ ਮਿੰਟ ਬਾਅਦ ਫ਼ੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਉਸਨੂੰ ਸਫ਼ਲ ਐਲਾਨਿਆ ਜਾ ਚੁੱਕਾ ਹੋਵੇ, ਉਸਦਾ ਰੋਲਬੈਕ ਪਹਿਲਾਂ ਹੀ ਛੱਡਿਆ ਜਾ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ।
ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਲੱਭਿਆ
ਅਸੀਂ ਇਸਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਬਣਾਇਆ: ਇੱਕ ਕੰਮ ਕਰਦੀ API ਲਈ, ਉਸਨੂੰ ਸੌਣ ਦਿੱਤਾ, ਫਿਰ ਇੱਕ ਅਜਿਹੀ ਤਬਦੀਲੀ ਨਾਲ ਦੁਬਾਰਾ ਪਬਲਿਸ਼ ਕੀਤਾ ਜੋ ਬੂਟ 'ਤੇ ਕਰੈਸ਼ ਹੁੰਦੀ ਸੀ। ਹੈਲਥ ਚੈੱਕ ਨੇ ਇਸਨੂੰ ਲਾਈਵ ਦਿਖਾਇਆ।
ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੀ: ਹਰ ਤਿੰਨ ਪਬਲਿਸ਼ਾਂ ਵਿੱਚ, ਐਪ ਹਰ ਬੂਟ 'ਤੇ ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਮਰ ਰਹੀ ਸੀ, ਫਿਰ ਵੀ ਚੈੱਕ ਜੋ ਗਿਣਤੀ ਤੁਲਨਾ ਕਰਦਾ ਸੀ ਉਹ ਦੋ ਝਾਤਾਂ ਵਿਚਕਾਰ ਕਦੇ ਨਹੀਂ ਵਧੀ।
ਹੱਲ: ਗਿਣਤੀ ਨਹੀਂ, ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਕਰੈਸ਼ ਤੁਲਨਾ ਕਰੋ
ਗਿਣਨ ਦੀ ਥਾਂ, ਹੁਣ ਚੈੱਕ ਪਬਲਿਸ਼ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦੇ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਕਰੈਸ਼ ਦਾ ਸਮਾਂ ਦੇਖਦਾ ਹੈ।
ਜੇ ਦੂਜੀ ਝਾਤ ਵਿੱਚ ਪਬਲਿਸ਼ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੋਈ ਵੀ ਕਰੈਸ਼ ਦਿਖਦਾ ਹੈ, ਤਾਂ ਚੈੱਕ ਉਡੀਕ ਕਰਕੇ ਤੀਜੀ ਵਾਰ ਦੇਖਦਾ ਹੈ। ਜੇ ਤੀਜੀ ਝਾਤ ਦਾ ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਕਰੈਸ਼ ਦੂਜੀ ਝਾਤ ਦੇ ਸਭ ਤੋਂ ਤਾਜ਼ੇ ਨਾਲੋਂ ਬਾਅਦ ਦਾ ਹੈ, ਤਾਂ ਮਸ਼ੀਨ ਉਸ ਵਿਚਕਾਰ ਫਿਰ ਕਰੈਸ਼ ਹੋਈ। ਉਹ ਚਾਲੂ ਨਹੀਂ ਰਹਿ ਰਹੀ, ਅਤੇ ਪਬਲਿਸ਼ ਇੱਕ ਸੁਨੇਹੇ ਨਾਲ ਫ਼ੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਕਿ ਮਸ਼ੀਨ ਪਬਲਿਸ਼ ਤੋਂ ਬਾਅਦ ਵਾਰ-ਵਾਰ ਕਰੈਸ਼ ਹੋਈ ਅਤੇ ਅਜੇ ਵੀ ਰੀਸਟਾਰਟ ਹੋ ਰਹੀ ਹੈ।
ਇਹ ਇਸ ਗੱਲ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ ਇਵੈਂਟ ਸੂਚੀ ਕਿੰਨੀ ਛੋਟੀ ਹੈ। ਪੰਜ ਇਵੈਂਟਾਂ ਦੀ ਖਿਸਕਦੀ ਖਿੜਕੀ ਇਹ ਛੁਪਾ ਸਕਦੀ ਹੈ ਕਿ ਕਿੰਨੇ ਕਰੈਸ਼ ਹੋਏ, ਪਰ ਇਹ ਨਹੀਂ ਛੁਪਾ ਸਕਦੀ ਕਿ ਹੁਣੇ ਇੱਕ ਨਵਾਂ ਹੋਇਆ ਹੈ, ਕਿਉਂਕਿ ਸਭ ਤੋਂ ਨਵਾਂ ਇਵੈਂਟ ਹਮੇਸ਼ਾ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
ਨਵੇਂ ਬਦਲਾਅ ਨਾਲ, ਸਥਾਨਕ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਸਹੀ ਵਿਹਾਰ ਕਰਦਾ ਹੈ: ਪਬਲਿਸ਼ ਫ਼ੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪਿਛਲਾ ਇਮੇਜ ਬਹਾਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ ਟੈਸਟ ਵੀ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਦੇ ਵਿਹਾਰ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ: ਹਰ ਝਾਤ ਇੱਕ ਕਰੈਸ਼ ਅਤੇ ਇੱਕ ਸ਼ੁਰੂਆਤ ਜੋੜਦੀ ਹੈ, ਅਤੇ ਸੂਚੀ ਪੰਜ ਤੱਕ ਕੱਟਦੀ ਹੈ, ਅਤੇ ਜਾਂਚਦਾ ਹੈ ਕਿ ਫ਼ੈਸਲਾ ਫ਼ੇਲ੍ਹ ਹੈ, ਪਾਸ ਨਹੀਂ।
ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ
- ਜਿਸ ਡੇਟਾ ਨੂੰ ਗਿਣ ਰਹੇ ਹੋ ਉਸਦਾ ਆਕਾਰ ਜਾਣੋ। ਸੀਮਾ ਵਾਲੀ ਸੂਚੀ 'ਤੇ ਗਿਣਤੀ ਭਰਨ ਤੋਂ ਬਾਅਦ ਕੋਈ ਅਰਥ ਨਹੀਂ ਰੱਖਦੀ। ਸੀਮਾ ਲੁਕੀ ਨਹੀਂ ਸੀ; ਅਸੀਂ ਬੱਸ ਜਾਂਚ ਨੂੰ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤਾ ਸੀ।
- "ਕੀ ਕੁਝ ਨਵਾਂ ਹੋਇਆ?" ਨੂੰ "ਕਿੰਨੇ ਹੋਏ?" ਨਾਲੋਂ ਤਰਜੀਹ ਦਿਓ। ਸਭ ਤੋਂ ਨਵਾਂ ਟਾਈਮਸਟੈਂਪ ਕੱਟੇ ਜਾਣ ਤੋਂ ਬਚਦਾ ਹੈ। ਕੁੱਲ ਗਿਣਤੀ ਨਹੀਂ ਬਚਦੀ।
- ਦੇਰ ਨਾਲ ਫ਼ੇਲ੍ਹ ਹੋਣਾ ਜਲਦੀ ਫ਼ੇਲ੍ਹ ਹੋਣ ਨਾਲੋਂ ਮਾੜਾ ਹੈ। ਉਹੀ ਟੁੱਟਿਆ ਬਿਲਡ ਠੀਕ ਹੈ ਜੇ ਪਬਲਿਸ਼ ਫ਼ੇਲ੍ਹ ਹੋ ਕੇ ਰੋਲ ਬੈਕ ਹੋ ਜਾਵੇ, ਪਰ ਜੇ ਪਹਿਲਾਂ ਸਫ਼ਲ ਐਲਾਨਿਆ ਜਾਵੇ ਤਾਂ ਸਾਈਟ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।
- ਅਸਲ ਹਾਲਾਤਾਂ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਓ। ਇਹ ਬੱਗ ਇੱਕ ਅਜਿਹੀ ਮਸ਼ੀਨ ਮੰਗਦਾ ਸੀ ਜੋ ਆਪਣੀ ਇਵੈਂਟ ਸੂਚੀ ਭਰਨ ਜੋਗੇ ਕਰੈਸ਼ ਕਰ ਚੁੱਕੀ ਹੋਵੇ। ਟੈਸਟ ਵਿੱਚ ਇੱਕ ਤੇਜ਼ ਕਰੈਸ਼ ਇਹ ਨਾ ਦਿਖਾਉਂਦਾ।
ਇਹ ਫ਼ਿਕਸ ਉਸੇ ਦਿਨ ਦੇ ਇੱਕ ਹੋਰ ਸੁਧਾਰ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਜਿਸ ਨੇ ਯਕੀਨੀ ਬਣਾਇਆ ਕਿ ਰੋਲਬੈਕ ਪੁਰਾਣਾ ਵਰਜਨ ਵਾਪਸ ਲਿਆਵੇ, ਨਾ ਕਿ ਉਸਨੂੰ ਮਿਟਾਵੇ: ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਕਦੇ ਵੀ ਕੰਮ ਕਰਦੇ ਬੈਕਐਂਡ ਨੂੰ ਨਹੀਂ ਮਿਟਾਉਂਦਾ। ਜੇ ਤੁਹਾਡੀ ਆਪਣੀ ਐਪ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਕਰੈਸ਼ ਹੋਣ ਕਾਰਨ ਪਬਲਿਸ਼ ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ ਪਬਲਿਸ਼ ਸਮੱਸਿਆ-ਨਿਵਾਰਣ ਡੌਕਸ ਅਤੇ ਸਾਡੀ AI ਨਾਲ ਬਣੀ ਐਪ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਗਾਈਡ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਹਨ।