Fix the lock order planner for ledger transfers

Review the AI's codeEasy10 minStripe style

Your task

An assistant's Go Transfer(from, to) locked from, then to. Under load, a transfer from X to Y and one from Y to X each held one lock. Each waited forever for the other, and the ledger froze. The fix plans the lock order from the account ids, so every caller takes the same lock first.

An assistant wrote plan_lock_order(transfers). It is in the editor. It has a bug. Find it and fix it.

Input and output:

  • transfers: one string per transfer, each meant to be "from_id>to_id". The list can be empty.
  • Return the lock plans, one string per valid transfer, in input order.

Rules the tests check:

  • Skip a line that does not split on > into exactly 2 parts, or where either id is empty.
  • When the two ids are equal, the plan is that id alone, such as "acct-5". A Go mutex cannot be locked twice by the same caller.
  • Otherwise the plan is "first>second", where first is the smaller id and second the larger one.
  • Compare ids as plain strings, character by character, by character code. So every uppercase letter sorts before every lowercase one, and acct-10 sorts before acct-9.
  • Ids are case sensitive: A and a are two different accounts.

Examples

plan_lock_order(transfers: list[str]) -> list[str]
Example 1
Inputplan_lock_order(["X>Y", "Y>X"])
Output["X>Y", "X>Y"]
Example 2
Inputplan_lock_order(["acct-9>acct-2", "acct-2>acct-9", "acct-5>acct-5"])
Output["acct-2>acct-9", "acct-2>acct-9", "acct-5"]