You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new UI for fetching slogs of a specific block is great, but often time we only care about a specific run (or more precisely a specific trigger).
The UX would look something like:
User enters a block height, and service returns a list of runs in that block, with information about each run (run number, how much computrons spent, trigger if available)
User selects a specific run to display / download.
The new contextual slog sender in u18 adds a label to all reported events for a given trigger, making querying more easy. However the original slog does not have such meta information.
The easiest to build the block and run info is likely to query for all cosmic-swingset-* events, and display the runs within a block. However while the cosmic-swingset block events have a blockHeight field, the trigger events do not, so 2 queries might be necessary to first determine the timestamp bounds. No matter what the trigger event can only be associated temporally with the subsequent run. See https://github.com/Agoric/agoric-sdk/blob/1dd458941b740258ee2d43de48a8a1b9e0fdcae8/packages/telemetry/src/context-aware-slog.js#L55-L81 and the rest of that file for more info.
Another approach might be to rely on the new contextualized slogs events in u18, and either adapt the causeway code to understand that structure, or transform the contextualized events back into slog events (the transform while it deletes some duplicate info from the payload is not destructive as that info is present in the context store in the labels). Such a transform might actually be useful on its own for backwards compatibility with the flurry of command line tools we have that accept slogs.
The text was updated successfully, but these errors were encountered:
The new UI for fetching slogs of a specific block is great, but often time we only care about a specific run (or more precisely a specific trigger).
The UX would look something like:
The new contextual slog sender in u18 adds a label to all reported events for a given trigger, making querying more easy. However the original slog does not have such meta information.
The easiest to build the block and run info is likely to query for all
cosmic-swingset-*
events, and display the runs within a block. However while the cosmic-swingset block events have ablockHeight
field, the trigger events do not, so 2 queries might be necessary to first determine the timestamp bounds. No matter what the trigger event can only be associated temporally with the subsequent run. See https://github.com/Agoric/agoric-sdk/blob/1dd458941b740258ee2d43de48a8a1b9e0fdcae8/packages/telemetry/src/context-aware-slog.js#L55-L81 and the rest of that file for more info.Another approach might be to rely on the new contextualized slogs events in u18, and either adapt the causeway code to understand that structure, or transform the contextualized events back into slog events (the transform while it deletes some duplicate info from the payload is not destructive as that info is present in the context store in the labels). Such a transform might actually be useful on its own for backwards compatibility with the flurry of command line tools we have that accept slogs.
The text was updated successfully, but these errors were encountered: