Διαχείριση σφαλμάτων του Tracking API: Πώς να διαχειρίζεστε μη έγκυρους αριθμούς παρακολούθησης, όρια ρυθμού και επαναπροσπάθειες

Διαχειριστείτε τα σφάλματα του API παρακολούθησης διαχωρίζοντας τις μη έγκυρες εισόδους, τις προσωρινές αποτυχίες, τα όρια ρυθμού και τα αποτελέσματα κατάστασης αποστολής. Απορρίψτε ή διορθώστε τους μη έγκυρους αριθμούς παρακολούθησης αντί να τους επαναλαμβάνετε αμετάβλητους, συντονίστε τον όγκο των αιτημάτων όταν επιβάλλεται περιορισμός ρυθμού και επαναλάβετε τις προσωρινές αποτυχίες με περιορισμένη εκθετική καθυστέρηση και τυχαιότητα. Πριν επαναλάβετε μια εγγραφή ή άλλο αίτημα εγγραφής, διαπιστώστε αν η πρώτη προσπάθεια ήταν επιτυχής.

Για τους προγραμματιστές που συνδέουν δεδομένα παρακολούθησης με ένα σύστημα διαχείρισης παραγγελιών, μια πλατφόρμα αποθήκης ή μια σελίδα παρακολούθησης που απευθύνεται στους πελάτες, ο στόχος δεν είναι απλώς λιγότερα αποτυχημένα αιτήματα. Είναι η αξιόπιστη ορατότητα των αποστολών χωρίς διπλές εγγραφές, καταιγισμό επαναλήψεων, παραπλανητικά μηνύματα παράδοσης ή περιττά αιτήματα υποστήριξης.

Κατηγοριοποιήστε την αποτυχία πριν επιλέξετε απόκριση

Μια ενσωμάτωση παρακολούθησης έχει αρκετά ξεχωριστά αποτελέσματα προς αξιολόγηση: αν ολοκληρώθηκε το αίτημα δικτύου, αν το API αποδέχθηκε τη λειτουργία, αν κάθε ζητούμενο αντικείμενο παρακολούθησης ολοκληρώθηκε επιτυχώς και αν είναι διαθέσιμα συμβάντα αποστολής. Η αντιμετώπιση και των τεσσάρων ως μίας μόνο ένδειξης επιτυχίας ή αποτυχίας δημιουργεί σφάλματα που μπορούν να αποφευχθούν.

Μια επιτυχής απόκριση HTTP δεν σημαίνει απαραίτητα ότι κάθε αντικείμενο μιας δέσμης ολοκληρώθηκε επιτυχώς. Αντίστροφα, μια επιτυχώς επεξεργασμένη αναζήτηση χωρίς συμβάντα παρακολούθησης δεν αποτελεί απαραίτητα αποτυχία του API. Ελέγξτε το σώμα της απόκρισης και εφαρμόστε την τεκμηριωμένη σημασία του παρόχου για κάθε αποτέλεσμα.

Κατάσταση	Προτεινόμενη ενέργεια	Επανάληψη αμετάβλητη;
Κακοσχηματισμένος αριθμός ή μη έγκυρο πεδίο αιτήματος	Επικυρώστε και διορθώστε την είσοδο	Όχι
Ελλιπή ή μη έγκυρα διαπιστευτήρια	Ελέγξτε τα διαπιστευτήρια, τα δικαιώματα και το περιβάλλον	Μόνο μετά τη διόρθωση
Απόκριση περιορισμού ρυθμού	Καθυστερήστε την επηρεαζόμενη εργασία και μειώστε την κοινή πίεση αιτημάτων	Μετά την απαιτούμενη αναμονή, εφόσον είναι ασφαλές
Προσωρινή αποτυχία υπηρεσίας	Εφαρμόστε περιορισμένη καθυστέρηση και ελέγξτε την ασφάλεια της λειτουργίας	Συνήθως, εντός προϋπολογισμού επαναλήψεων
Λήξη χρονικού ορίου μετά την υποβολή εγγραφής	Επαληθεύστε αν υπάρχει η εγγραφή	Όχι τυφλά
Αποδεκτή αναζήτηση χωρίς συμβάντα αποστολής	Ακολουθήστε τον τεκμηριωμένο κύκλο ζωής παρακολούθησης	Χρησιμοποιήστε προγραμματισμένη ανανέωση, όχι γρήγορες επαναλήψεις

Οι κωδικοί κατάστασης HTTP αποτελούν αφετηρία και όχι πλήρες, ειδικό για τον πάροχο δέντρο αποφάσεων. Το RFC 9110 ορίζει τη σημασιολογία του HTTP, ενώ το RFC 6585 ορίζει το 429 Too Many Requests. Η ενσωμάτωσή σας πρέπει επίσης να ερμηνεύει τους τεκμηριωμένους κωδικούς σφαλμάτων εφαρμογής και τα αποτελέσματα σε επίπεδο αντικειμένου.

Μη έγκυροι αριθμοί παρακολούθησης: διαχωρίστε την εσφαλμένη είσοδο από τα ελλιπή συμβάντα

Η ένδειξη «μη έγκυρος αριθμός παρακολούθησης» μπορεί να περιγράφει διαφορετικά προβλήματα: κακοσχηματισμένο αναγνωριστικό, μη υποστηριζόμενο συνδυασμό μεταφορέα και αριθμού, έλλειψη απαιτούμενου πεδίου μεταφορέα ή άλλη ειδική αποτυχία επικύρωσης του παρόχου. Μην θεωρείτε ότι ένας αριθμός είναι μη έγκυρος μόνο και μόνο επειδή δεν επιστρέφονται συμβάντα παρακολούθησης.

Επικυρώστε χωρίς να αλλοιώσετε το αναγνωριστικό

• Αποθηκεύστε τους αριθμούς παρακολούθησης ως συμβολοσειρές. Η αριθμητική αποθήκευση μπορεί να αφαιρέσει αρχικά μηδενικά ή να αλλοιώσει μεγάλα αναγνωριστικά.
• Διατηρήστε την αρχική είσοδο. Κρατήστε ξεχωριστή κανονικοποιημένη τιμή, ώστε οι μετασχηματισμοί να μπορούν να ελεγχθούν.
• Κανονικοποιήστε συντηρητικά. Αφαιρείτε τα περιβάλλοντα κενά όπου ενδείκνυται, αλλά αφαιρείτε εσωτερικούς χαρακτήρες ή αλλάζετε πεζά και κεφαλαία μόνο όταν το επιτρέπουν οι τεκμηριωμένοι κανόνες.
• Ελέγξτε τοπικά τα απαιτούμενα πεδία. Εντοπίστε κενά πεδία αριθμών, ελλείποντα αναγνωριστικά μεταφορέα και μη έγκυρες δομές αιτημάτων πριν από την αποστολή τους.
• Αποφύγετε μια καθολική κανονική έκφραση για αριθμούς παρακολούθησης. Ένας κανόνας σχεδιασμένος για έναν μεταφορέα μπορεί να απορρίψει έγκυρα αναγνωριστικά άλλου.
• Επιβεβαιώστε τι περιέχει το πεδίο. Ο αριθμός παραγγελίας, η αναφορά αποθήκης και ο αριθμός παρακολούθησης του μεταφορέα δεν είναι εναλλάξιμα, εκτός αν το endpoint τα υποστηρίζει ρητά.

Αν το API απορρίπτει ρητά την είσοδο, οδηγήστε την προς διόρθωση αντί για αυτόματο βρόχο επαναλήψεων. Συμπεριλάβετε χρήσιμο λόγο, όπως «απαιτείται αναγνωριστικό μεταφορέα», αντί να υποβαθμίζετε κάθε πρόβλημα επικύρωσης σε «η παρακολούθηση απέτυχε».

Αντιμετωπίστε την «απουσία συμβάντων» ως ξεχωριστή κατάσταση

Μια αποστολή μπορεί να διαθέτει αναγνωριστικό παρακολούθησης πριν γίνουν διαθέσιμα χρήσιμα συμβάντα κίνησης. Η σωστή απόκριση εξαρτάται από το τεκμηριωμένο μοντέλο κατάστασης του API και το πλαίσιο της αποστολής. Ελέγξτε αν το αναγνωριστικό προήλθε από το σύστημα αποστολών, αν η επιλογή μεταφορέα είναι σωστή και αν η απόκριση υποδεικνύει δεδομένα σε αναμονή αντί για απορριφθείσα είσοδο.

Χρησιμοποιήστε ξεχωριστές εσωτερικές καταστάσεις όπως input_rejected, awaiting_events και temporarily_unavailable. Πρόκειται για προτεινόμενες καταστάσεις εφαρμογής και όχι για τυποποιημένες τιμές API. Βοηθούν να αποτραπεί η μετατροπή ενός προσωρινού κενού δεδομένων σε ανακριβές μήνυμα προς τον πελάτη.

Διαχειριστείτε τα όρια ρυθμού σε όλη την ενσωμάτωση και όχι ανά worker

Το RFC 6585 ορίζει το HTTP 429 ως απόκριση περιορισμού ρυθμού και επιτρέπει να περιλαμβάνει κεφαλίδα Retry-After. Το πρότυπο δεν καθορίζει καθολικό όριο ή μέθοδο καταμέτρησης για τα API παρακολούθησης. Τα όρια μπορεί να τεκμηριώνονται ανά λογαριασμό, διαπιστευτήριο, endpoint ή άλλο πεδίο εφαρμογής· χρησιμοποιήστε τους πραγματικούς κανόνες του παρόχου.

Το RFC 9110 καθορίζει δύο μορφές για το Retry-After: μη αρνητικό αριθμό δευτερολέπτων ή ημερομηνία HTTP. Αναλύστε και τις δύο. Αν η τιμή είναι ημερομηνία, υπολογίστε προσεκτικά την υπολειπόμενη αναμονή και λάβετε υπόψη τις διαφορές ρολογιού. Αν λείπει ή δεν μπορεί να χρησιμοποιηθεί, εφαρμόστε την προ configured εφεδρική πολιτική καθυστέρησης.

Το να κοιμάται ανεξάρτητα ένας worker δεν αρκεί όταν άλλοι workers συνεχίζουν να χρησιμοποιούν το ίδιο όριο. Τοποθετήστε τον έλεγχο ρυθμού στο κοινό όριο για το σχετικό διαπιστευτήριο ή τον λογαριασμό. Ένας κεντρικός προγραμματιστής, ένας κοινόχρηστος κάδος διακριτικών ή αντίστοιχος κατανεμημένος έλεγχος μπορούν να συντονίσουν αυτή την κίνηση.

1. Εντοπίστε το επηρεαζόμενο πεδίο. Καθορίστε σε ποιο endpoint, διαπιστευτήριο ή λογαριασμό εφαρμόζεται το όριο.
2. Σεβαστείτε την οδηγία αναμονής του διακομιστή. Μην προγραμματίζετε επανάληψη νωρίτερα από όσο επιτρέπει μια έγκυρη τιμή Retry-After.
3. Καθυστερήστε την επηρεαζόμενη εργασία στην ουρά. Αποφύγετε να μπλοκάρετε άσχετη κίνηση όταν τα όρια είναι πραγματικά ανεξάρτητα.
4. Μειώστε τον ταυτόχρονο αριθμό ή τη συχνότητα αιτημάτων. Η μία αναμονή χωρίς αλλαγή στο μοτίβο αιτημάτων μπορεί να δημιουργήσει ξανά το ίδιο πρόβλημα.
5. Συνεχίστε με διαστήματα. Όταν λήξει η αναμονή, μην απελευθερώσετε ολόκληρη την εκκρεμότητα ταυτόχρονα.

Όπου υποστηρίζεται, η ομαδοποίηση μπορεί να μειώσει τον αριθμό αιτημάτων, αλλά πρέπει να τηρεί τους τεκμηριωμένους κανόνες μεγέθους δέσμης και καταμέτρησης. Μην θεωρείτε ότι μία δέσμη καταναλώνει μία μονάδα ορίου. Ομοίως, χρησιμοποιήστε webhooks όπου είναι διαθέσιμα για να μειώσετε την περιττή περιοδική αναζήτηση, διατηρώντας παράλληλα τη διαδικασία συμφωνίας που απαιτεί η ενσωμάτωσή σας.

Χρησιμοποιήστε περιορισμένες επαναλήψεις με καθυστέρηση και τυχαιότητα

Οι επαναλήψεις είναι κατάλληλες όταν μια αποτυχία μπορεί να αποκατασταθεί χωρίς αλλαγή του αιτήματος και η επανάληψη της λειτουργίας είναι ασφαλής. Οι προσωρινές αποτυχίες σύνδεσης και ορισμένα σφάλματα διακομιστή μπορούν να ανήκουν σε αυτή την κατηγορία. Ένα κακοσχηματισμένο payload, μη έγκυρο διαπιστευτήριο ή μόνιμο πρόβλημα δικαιωμάτων απαιτεί γενικά διόρθωση.

Μια πρακτική εφεδρική λύση είναι η περιορισμένη εκθετική καθυστέρηση με πλήρη τυχαιότητα:

backoff_window = min(max_delay, base_delay * 2^retry_index)
jitter_delay = random(0, backoff_window)
next_delay = max(valid_retry_after_delay, jitter_delay)

Εδώ, το retry_index ξεκινά από μηδέν για την πρώτη επανάληψη και ένα απόν Retry-After δεν προσθέτει ελάχιστη αναμονή. Πρόκειται για επιλογές υλοποίησης και όχι για υποχρεωτικό αλγόριθμο HTTP. Επιλέξτε τη βασική καθυστέρηση, το ανώτατο όριο, το όριο προσπαθειών και τη συνολική προθεσμία με βάση τον φόρτο εργασίας σας και τις οδηγίες του παρόχου.

Η τυχαιότητα κατανέμει τα αιτήματα στον χρόνο αντί να τα επαναλαμβάνει κάθε worker στο ίδιο χρονοδιάγραμμα. Το όριο καθυστέρησης περιορίζει την εκθετική συνιστώσα· δεν πρέπει να υπερισχύει μιας μεγαλύτερης, έγκυρης αναμονής που ζητά ο διακομιστής. Αν αυτή η αναμονή υπερβαίνει την προθεσμία της εργασίας σας, αναβάλετε ή τερματίστε την εργασία σύμφωνα με την πολιτική, αντί να επαναλάβετε νωρίτερα.

Δώστε σε κάθε αλυσίδα επαναλήψεων ένα τέλος

• Όριο προσπαθειών: περιορίστε τον αριθμό πρόσθετων αιτημάτων.
• Όριο παρερχόμενου χρόνου: σταματήστε να επαναλαμβάνετε εργασία που έχει υπερβεί το χρήσιμο χρονικό παράθυρο επεξεργασίας.
• Ρητή ιδιοκτησία: επιλέξτε ποιο επίπεδο ελέγχει τις επαναλήψεις, ώστε οι επαναλήψεις του HTTP client και της ουράς να μην πολλαπλασιάζονται απροσδόκητα.
• Ανθεκτικός προγραμματισμός: αποθηκεύστε τις καθυστερημένες εργασίες αντί να βασίζεστε σε μεγάλες αναμονές μέσα σε βραχύβιες διεργασίες.
• Διαδρομή αποκατάστασης: στείλτε τις εξαντλημένες εργασίες σε ελέγξιμη ουρά αποτυχημένων εργασιών με λόγο και επόμενη ενέργεια.

Κατά τη διάρκεια παρατεταμένης διακοπής, εξετάστε έναν διακόπτη κυκλώματος που暂停 προσωρινά τις τακτικές κλήσεις και επιτρέπει ελεγχόμενες δοκιμές αποκατάστασης. Αυτό αποτελεί μοτίβο ανθεκτικότητας εφαρμογής και όχι ένδειξη ότι το απαιτεί κάποιος συγκεκριμένος πάροχος παρακολούθησης.

Επιλύστε τις αμφίσημες εγγραφές πριν τις στείλετε ξανά

Η λήξη χρονικού ορίου σημαίνει ότι η εφαρμογή σας δεν έλαβε πλήρη απόκριση. Δεν αποδεικνύει ότι ο διακομιστής απέρριψε ή δεν επεξεργάστηκε ποτέ το αίτημα. Η διάκριση αυτή έχει σημασία κατά την εγγραφή αριθμών παρακολούθησης ή την αλλαγή ρυθμίσεων παρακολούθησης.

Το RFC 9110 εξηγεί τις ιδιοσυγκρασιακές μεθόδους και προειδοποιεί κατά της αυτόματης επανάληψης μη ιδιοσυγκρασιακών αιτημάτων χωρίς βάση που να αποδεικνύει ότι η επανάληψη είναι ασφαλής ή ότι η αρχική λειτουργία δεν εφαρμόστηκε. Αξιολογήστε την τεκμηριωμένη σημασιολογία της λειτουργίας αντί να θεωρείτε ότι κάθε endpoint παρακολούθησης συμπεριφέρεται σαν αναζήτηση μόνο για ανάγνωση.

• Χρησιμοποιήστε μηχανισμό idempotency που τεκμηριώνεται από τον πάροχο, όταν είναι διαθέσιμος, ακολουθώντας το πεδίο εφαρμογής και τους κανόνες διατήρησής του.
• Διατηρήστε το ίδιο κλειδί idempotency για επαναλήψεις της ίδιας λογικής λειτουργίας· μην θεωρείτε ότι θα γίνει αποδεκτή οποιαδήποτε αυθαίρετη προσαρμοσμένη κεφαλίδα.
• Αν υποστηρίζεται, ελέγξτε την υπάρχουσα εγγραφή πριν επαναλάβετε μια αμφίσημη εγγραφή.
• Χρησιμοποιήστε τοπικό περιορισμό μοναδικότητας ευθυγραμμισμένο με την τεκμηριωμένη ταυτότητα αποστολής του παρόχου.
• Αποθηκεύστε το αποτέλεσμα της λειτουργίας, ώστε η επαναπαράδοση από την ουρά να μην ενεργοποιεί αυτόματα νέα εγγραφή.

Για λειτουργίες δέσμης, αποθηκεύστε το αποτέλεσμα κάθε αντικειμένου. Επαναλάβετε μόνο τα αντικείμενα που ταξινομήθηκαν ως προσωρινά αποτυχημένα και συμφωνήστε τα αντικείμενα των οποίων τα αποτελέσματα παραμένουν άγνωστα. Η επανάληψη ολόκληρης της δέσμης μπορεί να επαναλάβει επιτυχημένη εργασία και να καταναλώσει άσκοπα το όριο αιτημάτων.

Εφαρμόστε την πολιτική στον πάροχο παρακολούθησής σας

Για μια ενσωμάτωση 17TRACK, χρησιμοποιήστε τη σελίδα Tracking API και την επίσημη τεκμηρίωση API ως σημεία εκκίνησης για τη σύμβαση του συγκεκριμένου παρόχου. Διατηρήστε τον ταξινομητή σφαλμάτων σας παραμετροποιήσιμο αντί να ενσωματώνετε σκληρά υποθέσεις από έναν γενικό οδηγό HTTP.

Πριν από την υλοποίηση, επιβεβαιώστε το σχήμα αιτήματος του σχετικού endpoint, το περίβλημα απόκρισης, τις σημασίες των σφαλμάτων σε επίπεδο αντικειμένου, το πεδίο εφαρμογής του περιορισμού ρυθμού, τους περιορισμούς δέσμης και τους κανόνες για διπλές υποβολές. Όπου χρησιμοποιείτε παράδοση συμβάντων, επαληθεύστε επίσης τις απαιτήσεις επιβεβαίωσης, ελέγχου ταυτότητας και επαναπαράδοσης. Ο οδηγός αυτός δεν καθορίζει αριθμητικό όριο ρυθμού 17TRACK, πρόγραμμα επαναλήψεων ή λειτουργία idempotency.

Καταγράψτε κάθε επιβεβαιωμένο κανόνα σε αντιστοίχιση από την απόκριση του παρόχου προς την ενέργεια της εφαρμογής: διόρθωση εισόδου, επιδιόρθωση ρυθμίσεων, αναμονή, συμφωνία ή κλιμάκωση. Ένα μη αναγνωρισμένο σφάλμα πρέπει να διατηρεί το διαγνωστικό πλαίσιο και να ακολουθεί περιορισμένη εφεδρική διαδρομή, όχι να οδηγεί σε απεριόριστες επαναλήψεις.

Παρακολουθήστε την ποιότητα αποκατάστασης και δοκιμάστε τις διαδρομές αποτυχίας

Καταγράψτε τη λειτουργία, το endpoint, την κατάσταση HTTP, τον κωδικό σφάλματος εφαρμογής, τον αριθμό προσπάθειας, την καθυστέρηση, την επόμενη προγραμματισμένη ενέργεια και το αναγνωριστικό αιτήματος του παρόχου, όταν παρέχεται. Αποφύγετε την καταγραφή κλειδιών API, περιττών πληροφοριών διεύθυνσης ή μη περιορισμένων σωμάτων απόκρισης. Καλύψτε ή κατακερματίστε τα αναγνωριστικά παρακολούθησης όταν δεν χρειάζονται οι πλήρεις τιμές.

Παρακολουθήστε ξεχωριστά τα ποσοστά μη έγκυρων εισόδων, τον περιορισμό ρυθμού, την ηλικία της ουράς, τις εξαντλημένες επαναλήψεις και τον τελευταίο επιτυχή συγχρονισμό. Μια ενσωμάτωση μπορεί να έχει χαμηλό ποσοστό σφαλμάτων HTTP και παρ’ όλα αυτά να εμφανίζει παρωχημένες πληροφορίες αποστολής. Οι σελίδες που απευθύνονται στους πελάτες πρέπει να διατηρούν την τελευταία γνωστή κατάσταση αποστολής και να διακρίνουν μια αποτυχία ανανέωσης από μια εξαίρεση παράδοσης που αναφέρθηκε από τον μεταφορέα.

Πριν από την κυκλοφορία, δοκιμάστε κακοσχηματισμένη είσοδο, έγκυρα αναγνωριστικά χωρίς συμβάντα, και τις δύο μορφές του Retry-After, ελλείπουσες κεφαλίδες, μερικές αποτυχίες δέσμης, λήξεις χρονικού ορίου μετά από εγγραφές και επαναπαράδοση από την ουρά. Προσομοιώστε επίσης διακοπή αρκετά μεγάλη ώστε να εξαντληθεί ο προϋπολογισμός επαναλήψεων. Η δοκιμή επιτυγχάνει μόνο όταν η εργασία σταματά ή αναβάλλεται προβλέψιμα, τα επιτυχημένα αντικείμενα δεν επαναλαμβάνονται άσκοπα και τα αποτυχημένα αντικείμενα παραμένουν ανακτήσιμα.

Συχνές ερωτήσεις

Πρέπει να γίνεται αυτόματη επανάληψη ενός μη έγκυρου αριθμού παρακολούθησης;

Όχι όταν το API απορρίπτει ρητά την είσοδο ως μη έγκυρη. Διορθώστε πρώτα τον αριθμό, την επιλογή μεταφορέα ή τα απαιτούμενα πεδία. Αν η απόκριση σημαίνει αντίθετα ότι τα συμβάντα αποστολής δεν είναι ακόμη διαθέσιμα, χρησιμοποιήστε την τεκμηριωμένη ροή ανανέωσης αντί να το αντιμετωπίζετε ως αποτυχία επικύρωσης.

Σημαίνει το HTTP 200 ότι ένα αίτημα δέσμης ολοκληρώθηκε πλήρως;

Όχι απαραίτητα. Ελέγξτε το σχήμα απόκρισης του παρόχου για αποτελέσματα σε επίπεδο λειτουργίας και αντικειμένου. Αποθηκεύστε τις επιτυχίες και απομονώστε τις αποτυχίες, ώστε η επανάληψη ενός αντικειμένου να μην επαναλαμβάνει άσκοπα τα υπόλοιπα.

Πόσες προσπάθειες επανάληψης πρέπει να επιτρέπει μια ενσωμάτωση παρακολούθησης;

Δεν υπάρχει καθολικός αριθμός. Ορίστε τόσο όριο προσπαθειών όσο και προϋπολογισμό παρερχόμενου χρόνου με βάση τις οδηγίες του παρόχου, την ασφάλεια της λειτουργίας και το χρονικό διάστημα κατά το οποίο το αποτέλεσμα παραμένει χρήσιμο. Ένας προγραμματισμένος συγχρονισμός στο παρασκήνιο μπορεί να αντέχει διαφορετικό παράθυρο αποκατάστασης από ένα διαδραστικό αίτημα πελάτη.

Πρέπει μια λήξη χρονικού ορίου να χαρακτηρίζει αμέσως μια αποστολή ως αποτυχημένη;

Όχι. Η λήξη χρονικού ορίου ενός αιτήματος είναι αποτέλεσμα της ενσωμάτωσης και όχι συμβάν αποστολής. Διατηρήστε την τελευταία γνωστή κατάσταση παρακολούθησης, προγραμματίστε ασφαλή αποκατάσταση και αποφύγετε τη μετατροπή ενός προβλήματος συνδεσιμότητας σε ειδοποίηση αποτυχίας παράδοσης.

Τι πρέπει να συμβαίνει όταν εξαντλούνται οι επαναλήψεις;

Μετακινήστε την εργασία σε ανθεκτική ουρά αποτυχημένων εργασιών ή ελέγχου μαζί με το διαγνωστικό της πλαίσιο. Προσδιορίστε αν η αποκατάσταση απαιτεί διορθωμένη είσοδο, αποκατεστημένα διαπιστευτήρια, βοήθεια του παρόχου ή μεταγενέστερη ελεγχόμενη επανάληψη. Μην την απορρίπτετε σιωπηλά και μην ξεκινάτε ξανά τον ίδιο απεριόριστο κύκλο επαναλήψεων.

Πηγές

• RFC 9110: HTTP Semantics — σημασιολογία καταστάσεων HTTP, ιδιοσυγκρασιακές μέθοδοι, ζητήματα αυτόματης επανάληψης και το πεδίο Retry-After.
• RFC 6585: Additional HTTP Status Codes — ο ορισμός του 429 Too Many Requests και η προαιρετική κεφαλίδα Retry-After.
• 17TRACK Tracking API — επίσημο σημείο εισόδου για το προϊόν tracking API.
• 17TRACK API documentation — αναφορά για τον έλεγχο των ειδικών απαιτήσεων ενσωμάτωσης του παρόχου.