AI-assisted engineering/Reviewing AI code

Fix the ack handling in a reliable UDP sender

Review the AI's codeEasy10 min

Your task

Your control channel runs a small reliable-delivery layer over UDP: send a frame, wait for an ack carrying its sequence number, resend on timeout. The first version retried forever and wedged on a dead link. You model one send as the stream of events it sees and decide how it ends.

An assistant wrote reliable_send_result(seq, events, max_retries). It is in the editor. It has a bug. Find it and fix it.

Input and output:

seq: the sequence number of the frame in flight.
events: what the sender sees, in order. -1 is a timeout. Any other number is an ack carrying that sequence number.
max_retries: how many resends the sender may make.
Return "acked", "gave_up" or "pending".

Rules the tests check:

An ack ends the send with "acked" only when its number equals seq exactly. Each frame is acked on its own, so an ack for any other number, higher or lower, says nothing about this frame and is ignored.
On a timeout, if max_retries resends have already been made, return "gave_up". Otherwise make one more resend and keep waiting. With max_retries 0, the first timeout gives up.
If the events run out first, return "pending".

Examples

reliable_send_result(seq: int, events: list[int], max_retries: int) -> str

Example 1

Inputreliable_send_result(7, [7], 3)

Output"acked"

Example 2

Inputreliable_send_result(7, [-1, -1, 7], 3)

Output"acked"

Example 3

Inputreliable_send_result(7, [-1, -1, -1, -1], 3)

Output"gave_up"