Context
The package actively discourages synchronous execution on real hardware: QuantumExecutionException::synchronousUnsafe() tells the user to "Use dispatch() or queue() instead", and synchronous_safe: false makes ->run() throw. But there is currently no tool to actually run asynchronously — bin/python/circuit.py only ever calls the blocking task.result().
On real Braket QPUs a task is intrinsically async: you submit a circuit, get a task ARN back immediately, and poll/retrieve the result later (minutes to hours). Today the guard is a prohibition without an alternative: the package tells you not to run synchronously but gives you no supported way to run asynchronously.
This is a prerequisite for the production, multi-provider direction of the package: every real QPU backend is async, so a submit → store handle → retrieve flow is mandatory before the package can be used against real hardware in production.
Context
The package actively discourages synchronous execution on real hardware:
QuantumExecutionException::synchronousUnsafe()tells the user to "Use dispatch() or queue() instead", andsynchronous_safe: falsemakes->run()throw. But there is currently no tool to actually run asynchronously —bin/python/circuit.pyonly ever calls the blockingtask.result().On real Braket QPUs a task is intrinsically async: you submit a circuit, get a task ARN back immediately, and poll/retrieve the result later (minutes to hours). Today the guard is a prohibition without an alternative: the package tells you not to run synchronously but gives you no supported way to run asynchronously.
This is a prerequisite for the production, multi-provider direction of the package: every real QPU backend is async, so a submit → store handle → retrieve flow is mandatory before the package can be used against real hardware in production.