Design crypto trading order control API

You are implementing part of a simple crypto trading system that manages client orders. Each order can be in one of several states: NEW, ACTIVE, PAUSED, CANCELLED, or FILLED.

You need to support the following operations for a single order (you can assume order creation is already done):

1. pause(orderId): Temporarily pause an active order so that it will not be matched or executed while paused.
2. resume(orderId): Resume a paused order so that it becomes active again and can be matched.
3. cancel(orderId): Cancel an order so that it will never be executed in the future.

Rules and constraints:

• Valid state transitions are:
  • NEW -> ACTIVE
  • ACTIVE -> PAUSED
  • PAUSED -> ACTIVE (on resume)
  • ACTIVE -> CANCELLED
  • PAUSED -> CANCELLED
  • ACTIVE -> FILLED
• Once an order is in CANCELLED or FILLED, no further operations (pause, resume, or cancel) should change its state.
• pause on a non-ACTIVE order should be rejected.
• resume on a non-PAUSED order should be rejected.
• cancel on a CANCELLED or FILLED order should be a no-op or return an error (choose one behavior and be consistent).

Implement a small in-memory component that:

• Stores the current state of each order by orderId.
• Exposes methods pause, resume, and cancel that update state according to the rules above.
• Returns success/failure for each operation based on whether the transition is allowed.

Describe your data structures and implement the core logic for these operations.

Crypto Order State Controller

You are building a small in-memory component for a crypto trading system. Each order has an orderId and a current state. For this problem, you must process a list of API calls and update order states according to the allowed transitions.

Possible states are: NEW, ACTIVE, PAUSED, CANCELLED, and FILLED.

Supported operations:

• pause(orderId): allowed only when the order is currently ACTIVE, changing it to PAUSED
• resume(orderId): allowed only when the order is currently PAUSED, changing it to ACTIVE
• cancel(orderId): allowed only when the order is currently ACTIVE or PAUSED, changing it to CANCELLED

Rules:

• Once an order becomes CANCELLED or FILLED, no later operation may change it.
• Any invalid operation must return False and leave the state unchanged.
• If an operation references an unknown orderId, it also returns False.
• ACTIVE -> FILLED exists in the broader trading system, but this problem does not include a fill operation. A FILLED state may appear only in the initial data.

Given the initial list of orders and a list of operations, return:

1. A list of booleans showing whether each operation succeeded
2. The final state of every order in the same order as the input orders list

Examples

Example 1

Input: ([('o1', 'ACTIVE'), ('o2', 'PAUSED'), ('o3', 'FILLED')], [('pause', 'o1'), ('resume', 'o2'), ('cancel', 'o1'), ('cancel', 'o3')])
Output: ([True, True, True, False], [('o1', 'CANCELLED'), ('o2', 'ACTIVE'), ('o3', 'FILLED')])

Explanation: o1 is paused, o2 is resumed, then o1 is cancelled from PAUSED. Cancelling a FILLED order fails.

Example 2

Input: ([('a', 'NEW'), ('b', 'CANCELLED'), ('c', 'ACTIVE')], [('pause', 'a'), ('resume', 'c'), ('cancel', 'b'), ('cancel', 'x'), ('cancel', 'c'), ('pause', 'c')])
Output: ([False, False, False, False, True, False], [('a', 'NEW'), ('b', 'CANCELLED'), ('c', 'CANCELLED')])

Explanation: NEW cannot be paused, ACTIVE cannot be resumed, CANCELLED cannot be cancelled again, unknown order x fails, c is cancelled successfully, and then cannot be paused afterward.

Hints

1. A dictionary keyed by orderId lets you find and update an order's current state in O(1) time.
2. Instead of writing many nested if statements, consider storing allowed transitions in a table like (action, current_state) -> next_state.