ನಿಮ್ಮ ಇಮೇಲ್ ಪರೀಕ್ಷೆಗಳು ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಮತ್ತು CI ಗೆ ತಲುಪಿದ ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ನೀವು ಒಬ್ಬರೇ ಅಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ ಇದಕ್ಕೆ ನೀಡುವ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ಟೆಸ್ಟ್ ಕೋಡ್ನಲ್ಲಿ sleep ಕರೆಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಬಿಲ್ಡ್ ಪಾಸಾಗುವವರೆಗೆ ರಿಟ್ರೈ (retry) ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು. ಇದು ಒಂದು ದಿನದ ಮಟ್ಟಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ತಡೆಯಬಹುದು, ಆದರೆ ಇದು ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಇದು ಕೇವಲ ಅದನ್ನು ಮರೆಮಾಚುತ್ತದೆ ಅಷ್ಟೆ.
ನಿಜವಾದ ಸಮಸ್ಯೆ ಎಂದರೆ ನಿಮ್ಮ ಪರೀಕ್ಷೆಯು ಯಾವ ಇಮೇಲ್ ಅನ್ನು ತೆರೆಯಬೇಕೆಂದು ಹೇಗೆ ಗುರುತಿಸುತ್ತದೆ ಎಂಬುದಾಗಿದೆ.
ಹಂಚಿಕೆಯ ಇನ್ಬಾಕ್ಸ್ ಸಮಸ್ಯೆ (The Shared Inbox Problem)
ನಿಮ್ಮ ಲೋಕಲ್ ಮೆಷಿನ್ನಲ್ಲಿ, ನೀವು ಒಂದೇ ಬಾರಿಗೆ ಒಂದು ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತೀರಿ. ಒಂದು ಇಮೇಲ್ ಬರುತ್ತದೆ. ನೀವು ಅದನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಸರಳ.
CI ಎಂಬುದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಪರಿಸರವಾಗಿದೆ. ಒಂದೇ ಪಲ್ ರಿಕವೆಸ್ಟ್ (pull request) ನಾಲ್ಕು, ಎಂಟು ಅಥವಾ ಹದಿನಾರು ಸಮಾಂತರ ಕೆಲಸಗಳನ್ನು (parallel jobs) ಪ್ರಾರಂಭಿಸಬಹುದು. ಅವೆಲ್ಲವೂ ಒಂದು ಹಂಚಿಕೆಯ ಟೆಸ್ಟ್ ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ—ಅದು Mailosaur ಸರ್ವರ್ ಆಗಿರಲಿ, Mailtrap ಇನ್ಬಾಕ್ಸ್ ಆಗಿರಲಿ ಅಥವಾ ಸ್ಟೇಜಿಂಗ್ ಡೊಮೇನ್ನಲ್ಲಿರುವ ನೈಜ ಖಾತೆಯಾಗಿರಲಿ—ಅವುಗಳೆಲ್ಲವೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಬಕೆಟ್ಗೆ ಬರೆಯುತ್ತಿರುತ್ತವೆ. ಕೆಲಸ A ಪಾಸ್ವರ್ಡ್ ರಿಸೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಕೆಲಸ B ಆಮಂತ್ರಣವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಕೆಲಸ C ವಿಫಲವಾದ ವೆಲ್ಕಮ್ ಫ್ಲೋ ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಈ ಮಧ್ಯೆ, ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ವರ್ಕರ್ಸ್ ಮತ್ತು ಡೆಲಿವರಿ ಕ್ಯೂಗಳು ನೀವು ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಅನಿಶ್ಚಿತತೆಯನ್ನು (jitter) ಉಂಟುಮಾಡುತ್ತವೆ.
ಪ್ರತಿಯೊಂದು ಕೆಲಸವು ಆ ಹಂಚಿಕೆಯ ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ "Reset your password" ಎಂಬ ವಿಷಯವಿರುವ ಅತ್ಯಂತ ಹೊಸ ಸಂದೇಶವನ್ನು ಕೇಳಿದಾಗ, ಅದು ಒಂದು ಸ್ಪರ್ಧೆಯಾಗಿ (race) ಬದಲಾಗುತ್ತದೆ. ಗೆದ್ದ ಪರೀಕ್ಷೆಯು ಸರಿಯಾದ ಇಮೇಲ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಸೋತ ಪರೀಕ್ಷೆಯು ಇನ್ನೊಂದು ಕೆಲಸಕ್ಕಾಗಿ ಉದ್ದೇಶಿಸಲಾದ ಲಿಂಕ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತದೆ, ತಪ್ಪಾದ ವಿಷಯದ ವಿರುದ್ಧ ಅಸರ್ಟ್ (assert) ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಮಯದ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಇದು ಸಮಯದ ಸಮಸ್ಯೆಯಲ್ಲ. ಇದು ಗುರುತಿನ ಸಮಸ್ಯೆ (identity problem).
"ಅತ್ಯಂತ ಹೊಸ ಸಂದೇಶ" ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
ಈ ಅಸ್ಥಿರ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುವುದು ಸುಲಭ ಏಕೆಂದರೆ ಅದು ಸಹಜವಾಗಿ ಕಾಣುತ್ತದೆ:
- ಬಳಕೆದಾರರ ಫ್ಲೋ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ.
- ಪ್ರತಿ ಕೆಲವು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ (poll).
- ವಿಷಯದ ಸಾಲಿಗೆ (subject line) ಹೊಂದಿಕೆಯಾಗುವ ಅತ್ಯಂತ ಇತ್ತೀಚಿನ ಸಂದೇಶವನ್ನು ತೆರೆಯಿರಿ.
- ಮೊದಲ ಲಿಂಕ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿ ಮತ್ತು ಅಸರ್ಶನ್ಗಳನ್ನು (assertions) ಚಲಾಯಿಸಿ.
ಇದು ಕೇವಲ ಸಮಾಂತರತೆಯಿಂದ (parallelism) ಹೊರತಾಗಿ ಇತರ ಹಲವು ಕಾರಣಗಳಿಂದಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. ಹಿಂದಿನ ವಿಫಲವಾದ ರನ್ನಿಂದ ಬಂದ ರಿಟ್ರೈ ಸಂದೇಶವು ತಡವಾಗಿ ಬರಬಹುದು, ಮತ್ತು ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಪರೀಕ್ಷೆಯು ಪರಿಶೀಲಿಸುವ ಸಮಯದಲ್ಲಿ ಅದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅತ್ಯಂತ ಹೊಸ ಸಂದೇಶವಾಗಿ ಬದಲಾಗಬಹುದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಒಳಗಿರುವ ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ವರ್ಕರ್ಸ್ ಎರಡು ಇಮೇಲ್ಗಳನ್ನು ಕ್ಯೂನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಮೊದಲನೆಯದಕ್ಕಿಂತ ಮೊದಲು ಎರಡನೆಯದನ್ನು ತಲುಪಿಸಬಹುದು. ವಿಷಯದ ಸಾಲುಗಳು (Subject lines) ಮಾತ್ರ ದುರ್ಬಲ ಗುರುತಿಸುವಿಕೆಗಳಾಗಿವೆ; ನಿಮ್ಮ ಸ್ಟೇಜಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ ವಿಭಿನ್ನ ಮಾರ್ಗಗಳಿಂದ ಒಂದೇ ರೀತಿಯ ಇಮೇಲ್ಗಳನ್ನು ಕಳುಹಿಸಬಹುದು. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ (timestamp) ಮೂಲಕ ವಿಂಗಡಿಸುವುದು ನೋಡಿದಷ್ಟು ಕೆಟ್ಟದ್ದಲ್ಲ, ಆದರೆ CI ರನ್ನರ್ ಮತ್ತು ಮೇಲ್ ಪ್ರೊವೈಡರ್ ನಡುವಿನ ಸಮಯದ ವ್ಯತ್ಯಾಸವು (clock skew) ನಿಜವಾಗಿದ್ದು, ಮೇಲ್ APIಗಳು ಹೆಚ್ಚಾಗಿ ತಮ್ಮ ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ಕ್ಯಾಶ್ ಅಥವಾ ಬ್ಯಾಚ್ ಮಾಡುವುದರಿಂದ ಇದು ಇನ್ನೂ ಕಷ್ಟವಾಗುತ್ತದೆ.
ಕಾರ್ಯನಿBusy ಪರಿಸರಗಳಲ್ಲಿ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ಗಳು ಅಸ್ಪಷ್ಟವಾಗುತ್ತವೆ. ನಿಮಗೆ ನೇರವಾದ ಮಾರ್ಗ ಬೇಕು.
ರನ್ ಟೋಕನ್ (Run Token) ಎಂದರೆ ನಿಜವಾಗಿ ಏನು
ರನ್ ಟೋಕನ್ ಎಂದರೆ ನಿಮ್ಮ ಪರೀಕ್ಷೆಯ ಪ್ರಾರಂಭದಲ್ಲಿ ರಚಿಸಲಾದ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕಳುಹಿಸುವ ಇಮೇಲ್ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಒಂದು ವಿಶಿಷ್ಟ ಸ್ಟ್ರಿಂಗ್ (unique string) ಅಷ್ಟೆ. ಇದು ಬಳಕೆದಾರರಿಗೆ ಕಾಣುವಂತಿರಬೇಕಿಲ್ಲ ಮತ್ತು ಇದು ಸುಂದರವಾಗಿ ಕಾಣಬೇಕಿಲ್ಲದೇ ಇರಬಹುದು. ಈ ನಿರ್ದಿಷ್ಟ ಸಂದೇಶವು ಈ ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಯ ಚಾಲನೆಗೆ ಸೇರಿದ್ದೆಂದು ನೀವು ಸಾಬೀತುಪಡಿಸುವುದನ್ನು ಇದು ಖಚಿತಪಡಿಸಬೇಕಷ್ಟೆ.
ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳು ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಪರೀಕ್ಷೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು, ಈ ಕೆಳಗಿನಂತಹ ಟೋಕನ್ ಅನ್ನು ರಚಿಸಿ:
- ಒಂದು UUID:
550e8400-e29b-41d4-a716-446655440001 - ಬಿಲ್ಡ್-ಸ್ಕೋಪ್ಡ್ ರಿಕ್ವೆಸ್ಟ್ ಐಡಿ:
req_ci_build_4821_a7f3 - ಆಮಂತ್ರಣ ಸ್ಲಗ್ ಅಥವಾ ಮೆಟಾಡೇಟಾ ಸಫಿಕ್ಸ್:
signup-token-8k2m9n - ಟೆಸ್ಟ್ ರನ್ನರ್ನಿಂದ ರಚಿಸಲಾದ ರ್ಯಾಂಡಮ್ ಹೆಕ್ಸ್ ಸ್ಟ್ರಿಂಗ್:
test-run-a4f9c2d1
ನೀವು ಬ್ಯಾಕ್ಎಂಡ್ ಕೋಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವುದಾದರೆ, ಟೋಕನ್ ಅನ್ನು ಇಮೇಲ್ ಸಂದರ್ಭಕ್ಕೆ (context) ವರ್ಗಾಯಿಸಿ ಮತ್ತು ಬಾಡಿಯಲ್ಲಿ ಎಲ್ಲೋ ಒಂದು ಕಡೆ ಅದನ್ನು ಪ್ರದರ್ಶಿಸಿ. ನೀವು ಬ್ಲಾಕ್-ಬಾಕ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ ನೀವು ಬಳಸಬಹುದಾದ ರೆಫರೆನ್ಸ್ ಫೀಲ್ಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಪ್ಲಸ್ ಅಡ್ರೆಸಿಂಗ್ ಬಳಸಿ ಸ್ವೀಕರಿಸುವವರ ಲೋಕಲ್-ಪಾರ್ಟ್ನಲ್ಲಿ ಟೋಕನ್ ಅನ್ನು ಎಂಬೆಡ್ ಮಾಡಬಹುದು—testuser+a4f9c2d1@example.com—ಆದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಉಳಿಸಿಕೊಂಡು ಇಮೇಲ್ನಲ್ಲಿ ಮರಳಿ ಕಳುಹಿಸಿದರೆ ಮಾತ್ರ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಮೇಲ್ ಸಿಸ್ಟಮ್ ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಮೆಟಾಡೇಟಾ ಮೇಲೆ ಹೊಂದಾಣಿಕೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಇದರ ಉದ್ದೇಶ. ನಿಮ್ಮ ಪರೀಕ್ಷೆಯು ಹೊಂದಿರುವ ಡೇಟಾ ಮೇಲೆ ಹೊಂದಾಣಿಕೆ ಮಾಡಿ.
ವಿಶ್ವಾಸಾರ್ಹ ಮಾದರಿ (The Reliable Pattern)
"ಅತ್ಯಂತ ಹೊಸ ಸಂದೇಶ" ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕಿರಿದಾದ, ಟೋಕನ್-ಚಾಲಿತ ಹುಡುಕಾಟದೊಂದಿಗೆ ಬದಲಾಯಿಸಿ:
- ಯಾವುದೇ ಫ್ಲೋ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ರನ್ ಟೋಕನ್ ಅನ್ನು ರಚಿಸಿ.
- ಬಳಕೆದಾರರ ಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಅಪ್ಲಿಕೇಶನ್ ಹೊರಹೋಗುವ ಇಮೇಲ್ನಲ್ಲಿ ಟೋಕನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ಆ ಟೋಕನ್ಗೆ ಸೀಮಿತವಾದ ಫಿಲ್ಟರ್ಗಳೊಂದಿಗೆ ಮೇಲ್ ಪ್ರೊವೈಡರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. API ಬಾಡಿ ಸರ್ಚ್ ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಅದನ್ನು ಬಳಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ಅಭ್ಯರ್ಥಿ ಸಂದೇಶಗಳನ್ನು ಪಡೆದು ಕ್ಲೈಂಟ್-ಸೈಡ್ನಲ್ಲಿ ಅವುಗಳ ಬಾಡಿಗಳನ್ನು
grepಮಾಡಿ. - ಯಾವುದೇ ಲಿಂಕ್ಗಳು, ಬಟನ್ಗಳು ಅಥವಾ ವೆರಿಫಿಕೇಶನ್ ಕೋಡ್ಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಸಂದೇಶದ ಬಾಡಿಯಲ್ಲಿ ಟೋಕನ್ ಇರುವುದನ್ನು ಅಸರ್ಟ್ ಮಾಡಿ.
- ಅದರ ನಂತರವೇ ಕನ್ಫರ್ಮೇಷನ್ URL ಅಥವಾ ಕೋಡ್ ಅನ್ನು ಹೊರತೆಗೆಯಿರಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ.
ಈ ಕ್ರಮವು ಮುಖ್ಯವಾಗಿದೆ. ನೀವು ಮೊದಲು ಲಿಂಕ್ ಅನ್ನು ಹೊರತೆಗೆಯುತ್ತಾ ನಂತರ ಟೋಕನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದರೆ, ನೀವು ಈಗಾಗಲೇ ತಪ್ಪಾದ ಇಮೇಲ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿರುತ್ತೀರಿ. ಅಸರ್ಶನ್ ನಿಮ್ಮ ಗೇಟ್ಕೀಪರ್ ಆಗಿದೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಿಮ್ಮ ಹೆಲ್ಪರ್ Subject:"Welcome to AppName" AND Body:"a4f9c2d1" ಅನ್ನು ಹುಡುಕಬೇಕು, Subject:"Welcome to AppName" sort:-received ಅನ್ನು ಅಲ್ಲ. ಅನೇಕ ಇಮೇಲ್ ಪರೀಕ್ಷಾ ಸೇವೆಗಳು ಬಾಡಿ ಕಂಟೆಂಟ್ ಫಿಲ್ಟರ್ಗಳನ್ನು (body content filters) ಸ್ವೀಕರಿಸುವ ಸರ್ಚ್ APIಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ಅವುಗಳನ್ನು ಬಳಸಿ. ನೀವು ಸರಳವಾದ ಪ್ರೊವೈಡರ್ ಜೊತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಪೋಲಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು (polling logic) ಒಂದೇ ಕಡೆ ಇರಿಸಿ, ಇದರಿಂದ ನೀವು ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯಲ್ಲೂ ಸ್ಥಿರವಾಗಿ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಸೇರಿಸಬಹುದು.
ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಖರವಾಗಿಡಲು ಮೂರು ನಿಯಮಗಳು
ರನ್ ಟೋಕನ್ (run token) ಆಯ್ಕೆಯನ್ನು ನಿಖರಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ಹೇಗೆ ಪೋಲ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ತಪ್ಪುಗಳು ಸಂಭವಿಸಿದಾಗ ಏನು ಮಾಡುತ್ತೀರಿ ಎಂಬುದರ ಬಗ್ಗೆ ಶಿಸ್ತು ಅಗತ್ಯವಿದೆ.
ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಇನ್ಬಾಕ್ಸ್ ಸ್ಥಿತಿಯನ್ನು ಲಾಗ್ ಮಾಡಿ. ಪರೀಕ್ಷೆಯು ವಿಫಲವಾದಾಗ, ಇನ್ಬಾಕ್ಸ್ ಐಡెంಟಿಫೈಯರ್, ನೀವು ಹುಡುಕಿದ ಸಬ್ಜೆಕ್ಟ್ ಲೈನ್, ನಿಖರವಾದ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ವಿಂಡೋ ಮತ್ತು ಎಷ್ಟು ಸಂದೇಶಗಳು ನಿಮ್ಮ ಮಾನದಂಡಗಳಿಗೆ ಹೊಂದಿಕೆಯಾದವು ಎಂಬುದನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಿ. ಇದು ಅಸ್ಪಷ್ಟವಾದ "email not found" ಎಂಬ ದೋಷವನ್ನು ಒಂದು ಸ್ಪಷ್ಟವಾದ ಮಾಹಿತಿಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ಜಾಬ್ 7823, ಜಾಬ್ 7821 ರ ರಿಟ್ರೈ ಸಂದೇಶವನ್ನು (retry message) ಮೂರು ಸೆಕೆಂಡುಗಳ ನಂತರ ಬಂದ ಕಾರಣಕ್ಕಾಗಿ ಪಡೆದಿದ್ದರೆ, ನಿಮ್ಮ ಲಾಗ್ಗಳು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸಬೇಕು. ಈ ಸಂದರ್ಭವಿಲ್ಲದೆ, ನೀವು ಸಮಯದ ವ್ಯತ್ಯಾಸವನ್ನು ದೂಷಿಸಿ ಮತ್ತೊಂದು sleep ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ.
ಎಲ್ಲಾ ಇಮೇಲ್ ಪೋಲಿಂಗ್ ಅನ್ನು ಒಂದೇ ಹೆಲ್ಪರ್ ಫೈಲ್ನಲ್ಲಿ ಇರಿಸಿ. setTimeout ಮತ್ತು cy.task ಕರೆಗಳನ್ನು ಇಪ್ಪತ್ತು ಪರೀಕ್ಷಾ ಫೈಲ್ಗಳಲ್ಲಿ ಹರಡಬೇಡಿ. ಸಂದೇಶಗಳಿಗಾಗಿ ಕಾಯುವ, API ಕರೆಯನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವ (retry) ಮತ್ತು ಬ್ಯಾಕಫ್ (backoff) ಅನ್ವಯಿಸುವ ಲಾಜಿಕ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ. ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯು ಒಂದೇ ಹೆಲ್ಪರ್ ಅನ್ನು ಬಳಸಿದರೆ, ನಿಮ್ಮ ಫಿಲ್ಟರಿಂಗ್ ನಿಯಮಗಳು ಸ್ಥಿರವಾಗಿರುತ್ತವೆ ಮತ್ತು ನೀವು ಸರ್ಚ್ ಲಾಜಿಕ್ ಅನ್ನು ಸುಧಾರಿಸಿದಾಗ, ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯೂ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತದೆ. ಇದು ಟೋಕನ್ ಪರಿಶೀಲನೆಯನ್ನು ಜಾರಿಗೊಳಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ; ಒಂದು ವೇಳೆ ಹೆಲ್ಪರ್ ಟೋಕನ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಬಯಸಿದರೆ, ಯಾರೂ ಅಚಾನಕ್ಕಾಗಿ "latest message" ಎಂಬ ಸುಲಭ ಮಾರ್ಗವನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ನಿಮ್ಮ ರಿಟ್ರೈಗಳನ್ನು (retries) ಗಮನಿಸಿ. CI ಯಲ್ಲಿ ಪರೀಕ್ಷೆಯ ರಿಟ್ರೈಗಳು ಸಾಮಾನ್ಯ, ಆದರೆ ಪ್ರತಿ ರಿಟ್ರೈ ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಮತ್ತೊಂದು ಇಮೇಲ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ನಿಮ್ಮ ಪರೀಕ್ಷೆಯು ಮೂರನೇ ಪ್ರಯತ್ನದಲ್ಲಿ ಯಶಸ್ವಿಯಾದರೆ, ನೀವು ಸಂಭ್ರಮಿಸಿ ಮುಂದೆ ಹೋಗಬಹುದು. ಆದರೆ ನೀವು ಗಮನಿಸದ ವಿಷಯವೆಂದರೆ, ಮೊದಲ ಮತ್ತು ಎರಡನೇ ಪ್ರಯತ್ನಗಳು ಒಂದು ನೈಜ ಬಗ್ ಅನ್ನು—ರೇಸ್ ಕಂಡೀಷನ್ (race condition), ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಸೆಂಡ್ ಅಥವಾ ಮಿಸ್ಸಿಂಗ್ ಇಂಡೆಕ್ಸ್—ಎಂದನ್ನು ಬಹಿರಂಗಪಡಿಸಿರಬಹುದು, ಆದರೆ ಹೆಚ್ಚುವರಿ ಸಂದೇಶಗಳು ಅದನ್ನು ಮರೆಮಾಚಿರಬಹುದು. ನೀವು ರಿಟ್ರೈಗಳನ್ನು ಬಳಸಲೇಬೇಕೆಂದಿದ್ದರೆ, ವೈಫಲ್ಯದ ನಂತರ ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಡ್ಯೂಪ್ಲಿಕೇಟ್ಗಳು ಇವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿ, ನಿಮ್ಮ ಪ್ರೊವೈಡರ್ ಡೈನಾಮಿಕ್ ಇನ್ಬಾಸ್ಗಳನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಕ್ಲೀನ್ ಮಾಡುವುದನ್ನು ಅಥವಾ ಪ್ರತಿ ಜಾಬ್ಗೆ ವಿಶಿಷ್ಟ ವಿಳಾಸವನ್ನು ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ. ರಿಟ್ರೈಗಳು ಅನಿಶ್ಚಿತ ಆಯ್ಕೆ ಲಾಜಿಕ್ ಅನ್ನು (unreliable selection logic) ಮುಚ್ಚಿಹಾಕುವ ತಂತ್ರವಾಗಬಾರದು.
ನಿಜವಾದ ಸಾರಾಂಶ
ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ದಿನಾಂಕದ ಮೂಲಕ ವಿಂಗಡಿಸಿ (sorting) ಮೊದಲ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುವುದು ಪರೀಕ್ಷೆಯಲ್ಲ. ಅದು ಕೋಡ್ನ ರೂಪದಲ್ಲಿರುವ ಕೇವಲ ಊಹೆಯಾಗಿದೆ. ರನ್ ಟೋಕನ್ನಿಂದ ಯಾವುದೇ ಹೆಚ್ಚಿನ ವೆಚ್ಚವಾಗುವುದಿಲ್ಲ—ಒಂದು ಸ್ಟ್ರಿಂಗ್ ವೇರಿಯಬಲ್, ಒಂದು ಹೆಚ್ಚುವರಿ ಫಿಲ್ಟರ್ ಪ್ಯಾರಾಮೀಟರ್, ಬಹುಶಃ ಒಂದು ಸಣ್ಣ ಟೆಂಪ್ಲೇಟ್ ಬದಲಾವಣೆ—ಮತ್ತು ಇದು ನಿಮ್ಮ ಪರೀಕ್ಷೆಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಗುರುತನ್ನು (deterministic identity) ನೀಡುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಮುಂದೆ ಇರುವ ಸಂದೇಶವು ನೀವು ಈಗ ಚಲಾಯಿಸುತ್ತಿರುವ ರನ್ಗೆ ಸೇರಿದ್ದೆಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
sleepಗಳನ್ನು ಸೇರಿಸುವುದನ್ನು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಆಶಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಒಂದು ಟೋಕನ್ ಅನ್ನು ರಚಿಸಿ, ಅದನ್ನು ಇಮೇಲ್ನಲ್ಲಿ ಹಾಕಿ ಮತ್ತು ನೇರವಾಗಿ ಅದನ್ನು ಹುಡುಕಿ. ನಿಮ್ಮ CI ರನ್ಗಳು ವೇಗವಾಗಿರುತ್ತವೆ, ನಿಮ್ಮ ಲಾಗ್ಗಳು ಓದಲು ಸುಲಭವಾಗಿರುತ್ತವೆ ಮತ್ತು ಇಮೇಲ್ ಸೂಟ್ ನಿಮಗೆ ಹೇಳುತ್ತಿರುವುದನ್ನು ನೀವು ಅಂತಿಮವಾಗಿ ನಂಬಲೊಪ್ಪುವಿರಿ.