bluesky / event-model

data model for event-based data collection and analysis
https://blueskyproject.io/event-model
BSD 3-Clause "New" or "Revised" License
13 stars 30 forks source link

Slight difference between the current bluesky bundler and event model #259

Closed evalott100 closed 1 year ago

evalott100 commented 1 year ago

First problem

In the below snippet of code , the descriptor name is added to the event_list as a key, with number of events of 1, even if the descriptor hasn't had any code inserted.

    if name not in streams:
        streams[name] = set(data_keys)
        event_counters[name] = 1

This causes a num_events to be inaccurate causing the following behaviour:

    assert h.stop['num_events'] == {'primary': 0}

instead of what is depicted in the following assertion, as well as

    assert h.stop['num_events'] == {'primary': 0, 'baseline': 2}

in this assertion.

Do we keep the current bluesky behaviour by filtering out descriptors with an event_counter of 1, or do we add in the descriptor name with num_events of 0 directly? @danielballan @coretl

Second problem

The following code in the bluesky bundler isn't accounted for in event_model, it can be added very easily on compose_stop, let me know what you think.

            if bundle_name is None:
                # rare but possible via Msg('create', name='primary')
                continue
coretl commented 1 year ago

For 1) I think that as soon as we compose a descriptor then we should mention the number of events in the stop document, so {'primary': 0, 'baseline': 2} would be reasonable for me.

For 2) I don't understand how a bundle_name of None is added, and why if would be excluded from the stop document.

@danielballan @tacaswell any ideas?

coretl commented 1 year ago

For 2), assert when populating sequence_counters that bundle_name is not None