search

bluesky / bluesky-queueserver

Server for queueing plans
https://blueskyproject.io/bluesky-queueserver/
BSD 3-Clause "New" or "Revised" License
12 stars 22 forks source link

Adding an mv plan to the queue fails pydantic validation #310

Open canismarko opened 1 month ago

canismarko commented 1 month ago

I'm trying to add an item to the queue using the bluesky-queueserver-api package. It receives a response from the queueserver saying that Plan validation failed: Unable to generate pydantic-core schema for <class 'bluesky.protocols.NamedMovable'>.

Expected Behavior

The queue should contain a new item that will execute the bps.mv plan using the device specified. We should also get a response with response['status'] == True.

Current Behavior

The request fails, with an error message saying that pydantic validation failed. Here is the ipython session that had this issue.

https://gist.github.com/canismarko/ef234d5336e1f325139036a5384a4799

sim_motor_2 is an instance of ophyd_async.epics.motor.Motor. Further down, I tried with a different plan, namely bp.count, and this worked. In that case, sim_det is a threaded ophyd area detector, and I0 is an ophyd_async.core.StandardReadable object.

Steps to Reproduce (for bugs)

  1. Launch a queueserver which defines an ophyd-async epics motor in its queueserver startup (e.g. "sim_motor_2")
  2. In a separate python session, create and connect a bluesky_queueserver_api to the queueserver
  3. Create a bluesky plan to send to the queueserver: mv_plan = BPlan("mv", "sim_motor_2", 5)
  4. Add this item to the queue through the api: api.item_add(mv_plan)

Context

I have a GUI that uses the queueserver to execute plans. We have a window for adding the mv plan. This user selects the device for the mv plan, and the destination, then clicks a button that creates the BPlan item and send it to the queueserver.

Your Environment

Here are all the packages installed in the environment: https://gist.github.com/canismarko/ef234d5336e1f325139036a5384a4799#file-mamba-list I tried this with both bluesky 1.13, and bluesky installed directly from github (1.14.dev23+g3bce96b8). Here is the specific device that I'm using the make sim_motor_2: https://github.com/spc-group/haven/blob/f8855aa160f23c7f7222541c430f3d9c20cd1c14/src/haven/devices/motor.py#L19

whs92 commented 1 month ago

@danielballan this feels related to the problem reported by Zach Arthur in the community call last week.

whs92 commented 1 month ago

@canismarko you said this previously worked. What version of qserver api or qserver did it work with?

whs92 commented 1 month ago

And can you share the code from the qserver RE ipython env where you define the count and mv plans. Do you set any plan annotation?

whs92 commented 1 month ago

I don't get the problem if I do this: https://codebase.helmholtz.cloud/hzb/bluesky/beamlines_endstations/oaese/source/beamlinetools/-/blob/c7c57e4aca788e5c8b7d00be3234916cf5373ba4/beamlinetools/beamline_config/plans.py#L243

canismarko commented 1 month ago

@whs92 I set up a completely separate environment so I could test this better.

I found that actually the bluesky version is what determines whether this issue pops up:

† I couldn't test older bluesky-queueserver versions with bluesky==1.13.0 because those annotated plan stubs aren't recognized by bluesky-queueserver.

Do you set any plan annotation?

No, I just imported the standard bluesky plan stubs. Here is the queueserver startup code: https://gist.github.com/canismarko/3dde96e28c1dda1784d07801123d5934#file-queue_mv_plan_startup-py

dmgav commented 4 weeks ago

The issue is reproducible with Bluesky from main branch. It is being resolved in https://github.com/bluesky/bluesky-queueserver/pull/312 Currently it's half-working: the NamedMovable protocol is added and is recognized, but there are a few more problems.