undefined

points

[-]

> even if the client had passed a value it would have still done exactly the same thing, as the value of "v" (or anything from the request) is not used in that block

If they passed in any value, they would have entered the block and returned early with the results of FetchPrefixesPendingDeletion.

From the post:

> this was implemented as part of a regularly running sub-task that checks for BYOIP prefixes that should be removed, and then removes them.

They expected to drop into the block of code above, but since they didn't, they returned all routes.

by blibble4 hours ago|

parent|

[-]

okay so the code which returned everything isn't there

actual explanation: the API server by default returns everything. the client attempted to make a request to return "pending_deletes", but as the request was malformed, the API instead went down the default path, which returned everything. then the client deleted everything.

makes sense now

but is that explanation is even worse

because that means the code path was never tested?

by jbxntuehineoh4 hours ago|

parent|

[-]

or they tested it, but not with a dataset that contained prefixes not pending deletion

by bstsb5 hours ago|

prev|

[-]

doesn't look AI-generated. even if they have made a mistake, it's probably just from the rush of getting a postmortem out prior to root cause analysis

by subscribed2 hours ago|

prev|

[-]

That's weird. They only removed some 6 of our prefixes out of perhaps 40 we have with them, so something seems off in this explanation.

by himata41135 hours ago|

prev|

[-]

yep, no mention that re-advertised prefixes would be withdrawn again as well during the entire impact even after they shut it down.