Add resolvers to get details of specific runs

[tpoliaw]

On the instrumentSession object, run takes a scan number as these should
be unique within a session. On the root, it takes a run id as these
should be unique across tiled.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 21 lines in your changes missing coverage. Please review.
✅ Project coverage is 49.27%. Comparing base (6fb304d) to head (1ca9994).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/model.rs	0.00%	10 Missing ⚠️
src/clients.rs	0.00%	8 Missing ⚠️
src/model/node.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #89      +/-   ##
==========================================
- Coverage   51.00%   49.27%   -1.73%     
==========================================
  Files          13       13              
  Lines         600      621      +21     
==========================================
  Hits          306      306              
- Misses        294      315      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[abbiemery]

I like being able to look at one run, but now if you use the instrument session query you have both run and runs as a field option. Is this what you expected? While it became quickly apparent what is was for after graphiql shouted at me, it felt a bit confusing on the face of it. I don't have an opinion yet on how i'd want this to feel, but I thought i'd mention it.

Also, in my data I actually have two scans with different run_id's but the same scan number. This change only grabs one of them, not sure how it decides which. While in the world of production we keep track of these numbers to avoid clashes, anyone messing about in the weeds with our stack (Im thinking training rigs) may have this happen too. I think the choices are: return both things, Or specify on run _id instead. It's nicer for the user to be able to avoid uuid's but then we have a ui that isn't consistent.

[tpoliaw]

you have both run and runs as a field option. Is this what you expected?

Yes, one gets a single run, the other gets all the runs. Open to better naming ideas. all_runs and run?

This change only grabs one of them, not sure how it decides which

The first one returned by tiled. The problem with returning all matching scans is that you either have to always return a list when in the vast majority of cases with real data you're only going to get a single result, or have a flexible schema where you have to handle both cases which is a pain.

Or specify on run _id instead.

If the user has the run_id they don't need to go via the instrument_session, they can access the run directly via the run endpoint.

[abbiemery]

I do think this is better like this with instrument session only having runs. Going forward we should enable runs to take arguments to filter on.