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

struggling to visualize devnet vaultFactory upgrade problem #27

Open
dckc opened this issue Jan 3, 2025 · 2 comments
Open

struggling to visualize devnet vaultFactory upgrade problem #27

dckc opened this issue Jan 3, 2025 · 2 comments

Comments

@dckc
Copy link
Member

dckc commented Jan 3, 2025

@mhofman spent a long time poring over raw slogs to diagnose this problem. I'd like to get a more presentable version using this tool.

One version of the story is:

Timestamp Env Description
2024-12-30 13:45:08 devnet agoric-upgrade-18
2024-12-30 13:55:34 devnet replaceAllElectorates
2024-12-30 14:04:19 devnet vaultFactory upgraded 2->3
2024-12-30 14:04:33 devnet vaultFactory upgraded 3->4
2024-12-30 14:14:58 devnet upgradeVaults

I specified devnet block 6027800 and got an empty response. No diagnostic. Just an empty screen.

We found some of those details using other logging tools with queries such as...

"SwingSet:" ("coreProposal:" OR "upgraded from incarnation" OR "attempting to upgrade vat")

manifestGetterName is another search term I'm interested in.

cf.

@dckc
Copy link
Member Author

dckc commented Jan 3, 2025

I asked @mhofman if a 1-line-per-delivery slog summary would have helped.

He said he's not sure...

  • The main limitation is that the current causeway graph only shows what vat triggered the send and shows when the send was delivered, but it doesn't show during what delivery the send was made. So it's not currently possible to trace back through multiple calls what the original trigger was.
    • if we had diagonal arrows for sends / notifies
    • (and maybe an extra arrow from subscribe to notify delivery)
    • and clear start / stop of execution for each vat, then we would be able to more clearly visualize causal execution

Those are perhaps worth separate issues.

@mhofman
Copy link
Member

mhofman commented Jan 3, 2025

In https://github.com/Agoric/agoric-private/issues/235#issuecomment-2569807154 I described some of the breadcrumbs I followed. I think the main aspect is being able to go from syscall send to send delivery, from syscall notify to notify delivery, and from promise subscribe to notify delivery. From what I recall, causeway currently shows the intervat calls as an horizontal line from the sender vat to the receiving vat at the time of the delivery, so it's difficult to trace which delivery in the sender vat caused the send / notify. Also I think without a link from the subscribe (aka send) to the notify delivery, it's difficult to understand continuations.

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

2 participants