Prefect retry task tải web: chỉ thử lại lỗi tạm thời

Prefect retry task tải web là cách cấu hình cho task tải trang tự thử lại khi gặp lỗi, nhưng chỉ với lỗi có khả năng tự hết như máy chủ bận hay mất kết nối. Lỗi vĩnh viễn như trang 404 hay dữ liệu sai cấu trúc thì thử lại bao nhiêu lần cũng vậy, chỉ tốn thời gian và tạo thêm tải cho website. ProxyVN chạy Prefect 3.9.1 ngày 03/11/2026 với một máy chủ giả lập sáu loại phản hồi, đếm chính xác số lần máy chủ bị gọi, và kiểm task parse có bị chạy oan khi tải lỗi không. Bài ghi lại số lần thử, khoảng chờ và một cái bẫy về trạng thái flow.

Prefect retry task tải web: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và những gì bài không bàn.

Bài toán

Một flow crawl tải vài trăm URL rồi phân tích từng trang. Một số trang lỗi tạm thời: máy chủ trả 503 khi quá tải, kết nối bị ngắt giữa chừng. Một số trang lỗi vĩnh viễn: sản phẩm đã gỡ trả 404, trang trả về đúng nhưng thiếu trường giá vì website đổi cấu trúc. Đặt retries chung cho mọi lỗi làm flow chậm và gọi lại những trang không bao giờ thành công.

Đầu ra nghiệm thu

Đầu ra là nhật ký flow cho thấy lỗi tạm thời được thử lại đúng số lần, lỗi vĩnh viễn không được thử lại, và task parse không chạy khi task fetch tương ứng thất bại. Số lần thử phải được đếm ở phía máy chủ, không chỉ tin vào log của Prefect.

Ranh giới với hàng đợi và giới hạn tốc độ

Bài không bàn hàng đợi Celery hay cách phân phối task ra nhiều máy. Cũng không bàn timeout của proxy hay giới hạn tốc độ gọi API, vốn là chủ đề riêng. Trọng tâm là một tham số của Prefect: retry_condition_fn, và cách nó phân biệt lỗi đáng thử lại với lỗi không đáng.

Phiên bản đã khóa

Lab dùng prefect 3.9.1, httpx 0.28.1, Python 3.12 trên Windows. Flow chạy cục bộ, Prefect tự khởi động máy chủ tạm cho lần chạy. Không có Prefect Cloud, không có worker riêng. Thời gian chạy trong bài gồm cả thời gian khởi động máy chủ tạm.

Ai nên đọc

Người đang dùng Prefect để chạy crawl và thấy flow chậm bất thường khi website trả nhiều lỗi. Người mới đặt retries cho task và muốn biết task có thật sự thử lại đúng không. Người cần giải thích cho đồng đội vì sao một trang 404 không nên được gọi lại bốn lần.

Lịch sự với website nguồn

Mỗi lần thử lại là một request thêm tới máy chủ nguồn. Thử lại trang 404 ba lần nghĩa là gấp bốn lượng request vô ích cho trang đó. Với vài nghìn trang đã gỡ, con số này đáng kể. Retry đúng lỗi vừa giúp flow nhanh hơn, vừa giảm tải cho website bạn đang thu thập.

Retry có điều kiện trên task Prefect, giữ parse không chạy lại khi fetch lỗi với Prefect retry task tải web

Trước khi viết mã, cần nắm cơ chế retry của Prefect 3.

Ba tham số

Theo trang Retries trong tài liệu Prefect 3, task có ba tham số liên quan. retries là số lần thử lại tối đa. retry_delay_seconds là khoảng chờ, có thể là một số hoặc một danh sách cho từng lần. retry_condition_fn là hàm quyết định có thử lại hay không.

Hàm điều kiện nhận gì

retry_condition_fn nhận ba đối số: task, task_run và state. state là trạng thái thất bại của lần chạy vừa xong. Gọi state.result() sẽ ném lại ngoại lệ gốc, nhờ đó hàm biết task lỗi vì lý do gì. Hàm trả về True để thử lại, False để dừng.

Không có hàm điều kiện thì sao

Không truyền retry_condition_fn, task thử lại với mọi ngoại lệ cho tới khi hết số lần. Đây là hành vi mặc định, và cũng là nguồn gốc của vấn đề: 404 hay lỗi cấu trúc dữ liệu đều được thử lại như 503.

Tách fetch và parse

Fetch là task gọi mạng, có thể gặp lỗi tạm thời. Parse là task xử lý dữ liệu đã tải, không gọi mạng. Lỗi của parse gần như luôn là lỗi vĩnh viễn: cùng dữ liệu vào thì cùng lỗi ra. Tách hai task cho phép đặt chính sách retry khác nhau cho từng loại.

Retry ở task hay ở thư viện HTTP

httpx có cơ chế thử lại riêng ở tầng transport, nhưng chỉ cho lỗi kết nối, không cho mã 503. Có thể dùng cả hai tầng, nhưng dễ nhân số lần thử lên ngoài ý muốn: ba lần ở transport nhân bốn lần ở task là mười hai lần. Lab chỉ dùng retry của Prefect để số lần thử rõ ràng và hiện trong log.

Parse phụ thuộc fetch

Khi truyền kết quả của fetch làm đối số cho parse, Prefect hiểu parse phụ thuộc fetch. Nếu fetch thất bại, parse không có dữ liệu để chạy. Câu hỏi là Prefect xử lý parse thế nào trong trường hợp đó: bỏ qua, báo lỗi, hay chạy với giá trị rỗng. Lab sẽ trả lời.

Chia fetch task với parse task và cấu hình retries trong Prefect retry task tải web

Phần này trình bày mã của hai task và máy chủ giả lập.

Máy chủ giả lập sáu loại phản hồi

Máy chủ HTTP cục bộ ở cổng 9491 trả về theo đường dẫn. /ok trả JSON đúng. /flaky trả 503 hai lần đầu rồi trả JSON đúng. /dead luôn trả 503. /gone trả 404. /schema trả 200 với JSON thiếu trường price. Thêm một URL trỏ tới cổng 9499 không có gì nghe, để tạo lỗi kết nối.

Máy chủ đếm số lần mỗi đường dẫn bị gọi và ghi thời điểm. Đây là nguồn số liệu độc lập với Prefect.

Ba loại ngoại lệ

class Transient(Exception): pass
class Permanent(Exception): pass
class SchemaError(Exception): pass

Transient cho lỗi nên thử lại. Permanent cho lỗi HTTP không nên thử lại. SchemaError cho dữ liệu sai cấu trúc. Chuyển lỗi của thư viện HTTP về ba loại này giúp hàm điều kiện đơn giản và dễ đọc.

Task fetch

@task(retries=3, retry_delay_seconds=[0.5, 1, 2],
      retry_condition_fn=retry_if_transient)
def fetch(url):
    try:
        r = httpx.get(url, timeout=3)
    except httpx.TransportError as e:
        raise Transient(type(e).__name__)
    if r.status_code in (429, 500, 502, 503, 504):
        raise Transient(f"HTTP {r.status_code}")
    if r.status_code >= 400:
        raise Permanent(f"HTTP {r.status_code}")
    return r.json()

Lỗi kết nối và các mã 429, 500, 502, 503, 504 thành Transient. Các mã 4xx khác thành Permanent. Khoảng chờ tăng dần 0,5 giây, 1 giây, 2 giây.

Hàm điều kiện

Hàm điều kiện

def retry_if_transient(task, task_run, state) -> bool:
    try:
        state.result()
    except Transient:
        return True
    except Exception:
        return False
    return False

Hàm ném lại ngoại lệ gốc, bắt Transient thì trả True, mọi ngoại lệ khác trả False. Đơn giản, nhưng đủ để tách hai nhóm lỗi.

Timeout ngắn cho mỗi lần thử

Fetch đặt timeout 3 giây. Không có timeout, một máy chủ treo có thể giữ task chạy lâu, và retry không bao giờ được kích hoạt vì task chưa thất bại. Timeout ngắn biến treo thành lỗi tạm thời, rồi retry lo phần còn lại. Tổng thời gian tối đa cho một URL xấu là bốn lần timeout cộng ba khoảng chờ.

Task parse

Task parse nhận URL và dữ liệu đã tải, kiểm có trường price không, ném SchemaError nếu thiếu. Lab cố ý cho parse retries bằng 2 và không có hàm điều kiện, để thấy chuyện gì xảy ra với lỗi cấu trúc khi retry mặc định được bật. Một biến thể parse_no_retry có hàm điều kiện luôn trả False để so sánh.

Flow

@flow(name="crawl-retry")
def crawl(urls, parser):
    pairs = {}
    for u in urls:
        f = fetch.submit(u)
        g = parser.submit(u, f)
        pairs[u] = (f, g)
    for f, g in pairs.values():
        g.wait(); f.wait()
    return {u: (f.state.name, g.state.name) for u, (f, g) in pairs.items()}

submit chạy task song song. Truyền future f vào parser tạo phụ thuộc. Flow đợi mọi task xong rồi trả về trạng thái từng cặp.

Viết điều kiện retry theo loại exception cho Prefect retry task tải web

Phần này giải thích lựa chọn nhóm lỗi.

429 là tạm thời nhưng cần chờ lâu hơn

Mã 429 nghĩa là gọi quá nhanh. Nó là lỗi tạm thời, nhưng chờ 0,5 giây thường chưa đủ. Máy chủ có thể gửi header Retry-After cho biết nên chờ bao lâu. Hàm điều kiện của lab không đọc header này. Ngoài thực tế, nên tách 429 thành nhóm riêng với khoảng chờ dài hơn, hoặc tôn trọng Retry-After.

500 có nên thử lại không

Mã 500 nghĩa là máy chủ gặp lỗi nội bộ. Có lúc đó là lỗi tạm thời do quá tải, có lúc là lỗi cố định với một URL cụ thể, ví dụ trang sản phẩm có dữ liệu hỏng phía máy chủ. Lab xếp 500 vào nhóm tạm thời. Nếu thấy một URL luôn trả 500 qua nhiều lần chạy, nên chuyển nó sang danh sách vĩnh viễn.

404 và 410 là vĩnh viễn

Trang không tồn tại sẽ không tự xuất hiện sau hai giây. Thử lại chỉ tạo thêm request. 403 thường cũng vĩnh viễn trong phạm vi một lần chạy, vì nó là quyết định của máy chủ. Có ngoại lệ hiếm khi 403 do giới hạn tạm thời, nhưng mặc định coi là vĩnh viễn là an toàn hơn.

Lỗi kết nối là tạm thời

Kết nối bị từ chối, hết thời gian chờ, kết nối bị ngắt giữa chừng đều có thể tự hết. httpx gom các lỗi này vào nhóm TransportError. Bắt nhóm này thay vì từng lỗi cụ thể giúp mã gọn mà không bỏ sót.

Lỗi cấu trúc dữ liệu là vĩnh viễn

Trang trả 200 nhưng JSON thiếu trường price là lỗi cấu trúc. Tải lại sẽ nhận đúng JSON đó. Lỗi này nên báo ngay để người viết parser sửa, không nên thử lại.

Trang trả 200 nhưng là trang lỗi

Một số website trả mã 200 kèm nội dung báo lỗi, ví dụ trang thông báo bảo trì. Fetch chỉ kiểm mã HTTP sẽ coi đó là thành công, và parse sẽ ném SchemaError. Nếu trang bảo trì là tạm thời, lỗi này đáng thử lại sau, nhưng không phải sau vài giây. Cách hợp lý là parse nhận ra mẫu trang bảo trì và ném một loại lỗi riêng, để flow lần sau chạy lại URL đó.

Đặt lỗi cấu trúc ở parse, không ở fetch

Fetch chỉ kiểm mã HTTP. Việc dữ liệu có đủ trường hay không thuộc về parse. Nếu kiểm cấu trúc ngay trong fetch rồi ném Transient, trang lỗi cấu trúc sẽ bị tải lại nhiều lần. Phân vai rõ giữa hai task giúp chính sách retry không bị lẫn.

Ngoại lệ mang thông tin gì

Ngoại lệ Transient và Permanent trong lab mang mã HTTP hoặc tên lỗi kết nối. Thông tin này hiện trong log và trong thông điệp trạng thái task. Khi điều tra, đọc thông điệp là biết ngay lỗi thuộc loại nào mà không cần mở mã. Nên thêm cả URL vào thông điệp nếu log không tự ghi.

Hàm điều kiện nên ngắn

Hàm điều kiện chạy mỗi khi task thất bại. Nó không nên gọi mạng hay làm việc nặng. Trong lab, hàm chỉ ném lại và bắt ngoại lệ. Nếu cần quyết định phức tạp hơn, hãy đưa thông tin vào chính ngoại lệ, ví dụ thuộc tính cho biết có nên thử lại hay không.

Giả lập lỗi mạng tạm thời và lỗi schema không nên retry với Prefect retry task tải web

Phần này đọc kết quả từng URL.

Đếm ở hai phía

Lab đếm ở hai chỗ: máy chủ giả lập đếm số request nhận được, và task fetch tự đếm số lần được gọi. Hai con số khớp nhau ở mọi URL có máy chủ. Riêng URL lỗi kết nối chỉ có số đếm trong task, vì request không tới được máy chủ nào. Đếm hai phía giúp xác nhận log không nói sai.

Kết quả tổng hợp

Số lần thử

Bảng: Kết quả tổng hợp

URL	Fetch	Lần thử fetch	Máy chủ bị gọi	Parse	Lần gọi parse
/ok	Completed	1	1	Completed	1
/flaky	Completed	3	3	Completed	1
/dead	Failed	4	4	NotReady	0
/gone	Failed	1	1	NotReady	0
/schema	Completed	1	1	Failed	3
cổng 9499	Failed	4	không áp dụng	NotReady	0

/flaky thành công ở lần thứ ba

Máy chủ ghi ba lần gọi cho /flaky, hai lần đầu trả 503, lần ba trả 200. Log Prefect ghi Retry 1/3 sau 0,5 giây, Retry 2/3 sau 1 giây. Parse chạy một lần duy nhất với dữ liệu đúng. Đây là trường hợp retry đáng giá nhất.

/dead dừng sau bốn lần

/dead luôn trả 503. Máy chủ ghi bốn lần gọi: một lần đầu và ba lần thử lại. Task kết thúc Failed với thông điệp Transient: HTTP 503. Đúng bằng retries cộng một, không hơn.

/gone không được thử lại

/gone trả 404. Máy chủ ghi đúng một lần gọi. Log không có dòng Retry nào cho task này, chỉ có dòng Finished in state Failed với Permanent: HTTP 404. Hàm điều kiện đã làm đúng việc của nó.

Lỗi kết nối cũng được thử lại

URL cổng 9499 không có máy chủ nào nghe. Lab đếm bốn lần gọi fetch cho URL này, từ bộ đếm đặt trong chính task. Log ghi Retry 1/3 với Transient: ConnectError. Trên Windows, mỗi lần kết nối tới cổng đóng mất khoảng 2 giây trước khi báo lỗi, nên task này là task kết thúc muộn nhất.

Parse trên /schema bị thử lại ba lần

Fetch /schema thành công. Parse ném SchemaError vì thiếu trường price. Do parse có retries bằng 2 và không có hàm điều kiện, Prefect thử lại hai lần. Bộ đếm ghi ba lần gọi parse, cả ba đều lỗi giống nhau. Log hiện thông điệp đầy đủ: thiếu trường price, có gia và name.

Song song làm log xen kẽ

Sáu cặp task chạy song song, nên log các lần thử lại của /dead, /flaky và URL lỗi kết nối xen kẽ nhau. Mỗi dòng log có tên task run kèm mã ngắn, như fetch-2a5 hay fetch-d50. Muốn đọc lịch sử một URL, phải lọc theo tên task run, hoặc ghi URL vào thông điệp lỗi như lab làm.

Parse không điều kiện so với có điều kiện

Chạy lại /schema với parse_no_retry, hàm điều kiện luôn trả False. Bộ đếm ghi một lần gọi, task Failed ngay. Cùng lỗi, cùng kết quả, nhưng không tốn hai lần chạy thừa.

Với parse xử lý dữ liệu lớn, mỗi lần thử lại có thể mất vài giây. Hàng trăm trang lỗi cấu trúc nhân ba lần chạy là thời gian đáng kể.

Đếm attempts, delay và xác nhận parse không chạy với input lỗi trong Prefect retry task tải web

Phần này kiểm khoảng chờ và trạng thái của parse.

Khoảng chờ thực tế

Máy chủ ghi thời điểm mỗi lần /dead bị gọi. Khoảng cách giữa các lần là 0,79 giây, 1,3 giây và 2,23 giây. Cấu hình là 0,5 giây, 1 giây và 2 giây. Phần dư khoảng 0,25 tới 0,3 giây là thời gian Prefect ghi trạng thái và lên lịch lần chạy mới.

Khoảng chờ cấu hình là tối thiểu, không phải chính xác. Với khoảng chờ vài giây, phần dư không đáng kể. Với khoảng chờ rất ngắn, phần dư chiếm tỷ lệ lớn.

Parse ở trạng thái NotReady

Với /dead, /gone và URL lỗi kết nối, parse có trạng thái NotReady, số lần gọi bằng 0. Thông điệp ghi rằng task phía trên không đạt trạng thái COMPLETED. Prefect không chạy parse với giá trị rỗng, không chạy rồi báo lỗi, mà đánh dấu nó chưa sẵn sàng.

Đây là hành vi mong muốn. Parse không bao giờ nhận dữ liệu lỗi, và không ai phải viết thêm điều kiện kiểm đầu vào rỗng.

Kết quả của fetch được giữ

/flaky thành công ở lần thử thứ ba, và parse nhận đúng dữ liệu của lần thành công đó. Hai lần lỗi trước không để lại dữ liệu nào. Prefect chỉ truyền kết quả cuối cùng của task cho task phụ thuộc. Đây là lý do không cần tự viết vòng lặp thử lại trong fetch.

NotReady khác Failed

NotReady không phải lỗi của parse. Khi lọc task lỗi để báo cáo, nên tách hai trạng thái này. Báo cáo gộp chung sẽ cho thấy số task lỗi gấp đôi thực tế, và người sửa sẽ đi tìm lỗi trong parse trong khi nó chưa từng chạy.

Flow vẫn báo Completed

Flow báo Completed sai

Dù có ba task fetch Failed và một task parse Failed, flow kết thúc với trạng thái Completed, sau 23,5 giây. Lý do là flow trả về một dict bình thường chứa tên trạng thái, không trả về chính các trạng thái hay future. Prefect quyết định trạng thái flow dựa trên giá trị trả về, và một dict thường thì được coi là thành công.

Đây là cái bẫy lớn nhất của lab. Lịch chạy chỉ nhìn trạng thái flow sẽ thấy mọi thứ xanh trong khi một nửa số trang lỗi.

Lịch chạy chỉ nhìn trạng thái flow

Các công cụ lên lịch và cảnh báo thường chỉ đọc trạng thái cuối của flow. Completed thì không gửi gì, Failed thì gửi cảnh báo. Flow nuốt lỗi của task sẽ làm hệ thống cảnh báo im lặng. Nên kiểm tra định kỳ bằng cách cố ý chạy flow với một URL biết trước là lỗi, xem cảnh báo có tới không.

Cách làm flow phản ánh lỗi

Có vài cách. Trả về chính các future hoặc trạng thái, để Prefect tính trạng thái flow từ chúng. Hoặc đếm số task lỗi trong flow và tự ném ngoại lệ khi vượt ngưỡng. Lab chưa thử cách thứ nhất trên bản 3.9.1, nên không khẳng định kết quả cụ thể. Cách thứ hai luôn chạy được và cho phép đặt ngưỡng chấp nhận theo nghiệp vụ.

Thời gian tổng của flow

Flow mất 23,5 giây cho sáu URL. Phần lớn là thời gian khởi động máy chủ tạm của Prefect và bốn lần kết nối lỗi tới cổng đóng, mỗi lần khoảng 2 giây cộng khoảng chờ. Nếu không có hàm điều kiện, /gone cũng bị thử bốn lần, cộng thêm khoảng 3,5 giây chờ. Với hàng trăm trang 404, chênh lệch thành nhiều phút.

Đọc log để xác nhận

Log Prefect có dòng cho mỗi lần thử lại, dạng Retry n trên tổng số sẽ bắt đầu sau x giây. Đếm số dòng này cho mỗi task là cách kiểm nhanh không cần máy chủ giả lập. Lab đối chiếu số dòng Retry với bộ đếm phía máy chủ, hai nguồn khớp nhau.

Đầu ra nghiệm thu: flow log cho lỗi tạm thời và lỗi schema vĩnh viễn có số lần thử đúng của Prefect retry task tải web

Phần cuối gom kết quả thành bộ bàn giao.

Bộ bàn giao

Bộ bàn giao gồm tệp lab.py chứa máy chủ giả lập, hai task, hàm điều kiện và flow; tệp out.txt chứa log đầy đủ; bảng kết quả ở trên. Người nhận chạy lại lab.py, phải thấy /flaky gọi ba lần, /dead bốn lần, /gone một lần, parse trên /schema ba lần khi không có điều kiện và một lần khi có.

Tiêu chí đạt

Lỗi tạm thời được thử lại đúng retries cộng một lần. Lỗi vĩnh viễn được gọi đúng một lần. Parse không chạy khi fetch lỗi. Trạng thái flow phản ánh được việc có task lỗi, bằng cách tự ném ngoại lệ hoặc trả về trạng thái.

Thử lại ở lần chạy sau

Retry trong một lần chạy chỉ xử lý lỗi kéo dài vài giây. Máy chủ nguồn bảo trì một tiếng thì bốn lần thử trong vài giây đều thất bại. Với những URL như vậy, ghi lại danh sách URL thất bại vì lỗi tạm thời, rồi đưa vào lần chạy sau. Danh sách này khác danh sách URL 404, vốn nên được loại khỏi các lần chạy sau.

Quy tắc retry cho task tải web

Chuyển lỗi HTTP về nhóm tạm thời và vĩnh viễn ngay trong fetch. Dùng retry_condition_fn chỉ thử lại nhóm tạm thời. Đặt khoảng chờ tăng dần. Tắt retry cho parse hoặc cho nó điều kiện luôn từ chối. Không để flow trả dict thường mà bỏ qua trạng thái task.

Khi nào cần proxy với Prefect retry task tải web

Prefect không quyết định request đi qua đâu. Task fetch dùng httpx, nên proxy được cấu hình ở httpx hoặc qua biến môi trường mà httpx đọc. Retry không thay được proxy, và proxy không thay được retry.

Một số lỗi tạm thời thật ra do mạng không ổn định giữa máy crawl và website. Với website được phép thu thập, khi cần IP ổn định tại Việt Nam, anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN. Proxy không biến 404 thành 200 và không làm dữ liệu sai cấu trúc thành đúng. Vai trò hợp lệ của proxy được giải thích ở bài Web Scraping proxy là gì.

Lỗi của proxy cũng là lỗi tạm thời

Proxy chết hoặc từ chối kết nối sẽ hiện ra ở httpx dưới dạng lỗi kết nối, rơi vào nhóm Transient và được thử lại. Nếu proxy sai mật khẩu, httpx có thể nhận mã 407. Mã này không nằm trong danh sách tạm thời của lab, nên sẽ thành Permanent và không bị thử lại vô ích. Cách viết chuỗi proxy có xác thực đúng định dạng có trong bài định dạng proxy.

Ghi số lần thử vào kết quả

Kết quả cuối của mỗi URL nên có số lần thử và loại lỗi cuối cùng. Prefect giữ thông tin này trong task run, nhưng người dùng dữ liệu không mở Prefect. Đưa số lần thử vào dữ liệu xuất giúp phân tích sau này: nguồn nào hay cần thử lại, giờ nào hay bị 503.

Những gì lab chưa thử

Lab chưa thử Prefect Cloud, worker hay deployment. Chưa thử retry_jitter_factor để thêm độ ngẫu nhiên vào khoảng chờ. Chưa thử đọc header Retry-After. Chưa thử trả về future từ flow để xem trạng thái flow thay đổi thế nào. Thời gian kết nối lỗi khoảng 2 giây là đặc điểm của Windows, Linux thường báo lỗi nhanh hơn.

Checklist Prefect retry task tải web

Checklist

• Tách fetch và parse thành hai task.
• Chuyển lỗi về Transient, Permanent, SchemaError trong fetch.
• retry_condition_fn chỉ trả True với Transient.
• retry_delay_seconds tăng dần.
• 429 xử lý riêng, tôn trọng Retry-After nếu có.
• Parse không retry hoặc retry có điều kiện từ chối.
• Tách NotReady khỏi Failed khi báo cáo.
• Flow phản ánh task lỗi, không trả dict thường.

Câu hỏi thường gặp về Prefect retry task tải web

retry_condition_fn dùng để làm gì?

Để quyết định có thử lại task sau mỗi lần thất bại hay không, dựa trên ngoại lệ gốc lấy từ state.result().

Không có retry_condition_fn thì sao?

Task thử lại với mọi ngoại lệ. Lab cho thấy parse lỗi cấu trúc bị chạy ba lần thay vì một.

Task parse có chạy khi fetch lỗi không?

Không. Lab ghi parse ở trạng thái NotReady, số lần gọi bằng 0.

Khoảng chờ retry có chính xác không?

Gần đúng. Lab đo 0,79 giây, 1,3 giây và 2,23 giây cho cấu hình 0,5, 1 và 2 giây.

Vì sao flow báo Completed dù có task lỗi?

Vì flow trả về dict thường. Prefect tính trạng thái flow theo giá trị trả về, nên cần tự ném lỗi hoặc trả về trạng thái.

Retry có cần proxy không?

Không. Proxy cấu hình ở thư viện HTTP trong task fetch, độc lập với retry.

Prefect retry task tải web và những điều cần nhớ

Prefect retry task tải web chỉ có ích khi thử lại đúng loại lỗi. Lab trên Prefect 3.9.1 cho thấy retry_condition_fn giữ 404 ở một lần gọi, cho 503 và lỗi kết nối bốn lần, còn parse không chạy khi fetch lỗi. Hai chỗ cần chú ý là parse không có điều kiện bị thử lại oan, và flow trả dict thường vẫn báo Completed dù nhiều task lỗi. Cần IP tĩnh ổn định cho task tải trang trước khi cấu hình Prefect retry task tải web, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.