@spec get(GcpCompute.Config.t(), GcpCompute.Operation.t()) ::
  {:ok, GcpCompute.Operation.t()} | {:error, GcpCompute.Error.t()}

Fetch the current state of an operation (single GET, no waiting).

@spec poll_until_done(GcpCompute.Config.t(), GcpCompute.Operation.t(), keyword()) ::
  {:ok, GcpCompute.Operation.t()} | {:error, GcpCompute.Error.t()}

Repeatedly wait/2 until the operation is done or :timeout (ms) elapses.

Returns {:ok, done_operation} on success. If the operation completes with an error payload, returns {:error, %GcpCompute.Error{reason: :operation_failed}}. On timeout, {:error, %GcpCompute.Error{reason: :timeout}}.

Options

• :timeout — wall-clock budget in ms (default 5 minutes, 300000 ms). Must be a non-negative integer; :infinity is rejected with {:error, %GcpCompute.Error{reason: :invalid_argument}} rather than accepted into an unbounded loop. The deadline is checked between wait/2 calls; since each wait long-polls server-side, an in-flight call may overshoot the deadline by up to ~2 min.

• :poll_interval — floor delay in ms between wait/2 calls (default 1 s, 1000 ms), clamped to the remaining budget. This is not an optimisation: the Compute API may report a status this library cannot classify as done, which makes GcpCompute.Operation.done?/1 permanently false. Without a floor that turns the loop into thousands of authenticated requests — plus a token fetch each — i.e. a self-inflicted 429.

@spec wait(GcpCompute.Config.t(), GcpCompute.Operation.t()) ::
  {:ok, GcpCompute.Operation.t()} | {:error, GcpCompute.Error.t()}

Long-poll an operation once.

Calls the Compute operations.wait endpoint, which blocks server-side until the operation is DONE or ~2 minutes elapse, then returns the current state. The request carries a :receive_timeout of 150 s (150000 ms) so the socket outlives that server-side block.