Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the block fetching UX #26

Open
mhofman opened this issue Nov 26, 2024 · 0 comments
Open

Improve the block fetching UX #26

mhofman opened this issue Nov 26, 2024 · 0 comments

Comments

@mhofman
Copy link
Member

mhofman commented Nov 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant