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

Compile-time ChannelInterface subscription check #8207

Open
tbenr opened this issue Apr 16, 2024 · 4 comments
Open

Compile-time ChannelInterface subscription check #8207

tbenr opened this issue Apr 16, 2024 · 4 comments

Comments

@tbenr
Copy link
Contributor

tbenr commented Apr 16, 2024

When we introduce classes implementing a channel (ie SlotEventsChannel), we could forget to subscribe it during initialization (ie #8128)
So we end up implementing and passing all the unit tests (ie onSlot) but at runtime the class will never receive the events.

We should make sure (via an errorprone plugin or something) that the class instance get subscribed in production code (most of the time happens in BeaconChainController but is not always the case)

@zilm13
Copy link
Contributor

zilm13 commented Apr 16, 2024

Maybe some reflection stuff like we have for checking that channels have methods returning only void/Safefuture

@zilm13
Copy link
Contributor

zilm13 commented Apr 16, 2024

Another option could be

  • adding trace logging in EventChannels
  • get the list of all channels (from reflection?)
  • make an acceptance test on proposing node log that all getPublisher classes have subscribers (will need to enable few options or ignore few channels)

It could also check the order of subscriptions being before getPublisher (which is not true at the moment, but it would be good).

@tbenr
Copy link
Contributor Author

tbenr commented Apr 16, 2024

WRT the order, I think it might be a nice to have but the design of it explicitly allow late subscription (It is a feature, 'cose you may want to have different services in different modules initializing independently and async).
But in place where order can be followed, agree that it's a good thing to avoid missing events at initialization time.

@zilm13
Copy link
Contributor

zilm13 commented Apr 16, 2024

Yeah, I understand that part of init is async, some things could be subscribed later etc, but for core startup subscriptions wrong order could lead to miss of events. Just thinking aloud as hit it today.

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