-
Notifications
You must be signed in to change notification settings - Fork 11
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
Initial usage of share channels api (Only triggering metrics) #467
Conversation
server/plugin.go
Outdated
@@ -426,6 +428,36 @@ func (p *Plugin) OnActivate() error { | |||
} | |||
} | |||
|
|||
remoteID, err := p.API.RegisterPluginForSharedChannels(model.RegisterPluginOpts{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is important to notice that I'm registering everything here, and adding the hooks, and subscribing to channels, so the flag is just enabling and disabling the metric? Should we enable/disable the whole thing based on the configuration setting for monitoring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a setting to turn of shared channels, in which case the registration will fail. IMO that is enough should we want to disable it. However, that means OnActivate will fail and the plugin will not run. I think we need to decide if disabled shared channels is a fatal plugin error. Today, probably not a fatal error, but perhaps in the future. We could also look at the plugin enabling shared channels as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking the code, registration will succeed regardless of whether shared channels service is enabled. If disabled you simply won't get any sync messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shared channels service is enabled
Ah, this is interesting @wiggin77. Can you elaborate on what's required to enable? Does enabling force the user to enable the full shared channels experience, or can we selectively enable this just for plugins?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lieut-data Shared channels is enabled when a Pro or Enterprise license is used, and the ExperimentalSettings.EnableSharedChannels
config flag is true. I will soon look at always having the service run, but restricting UI.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #467 +/- ##
==========================================
- Coverage 41.55% 41.07% -0.48%
==========================================
Files 22 22
Lines 6175 6281 +106
==========================================
+ Hits 2566 2580 +14
- Misses 3393 3481 +88
- Partials 216 220 +4 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Few questions/comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
server/command.go
Outdated
@@ -221,6 +221,22 @@ func (p *Plugin) executeLinkCommand(args *model.CommandArgs, parameters []string | |||
return p.cmdError(args.UserId, args.ChannelId, "Error occurred while saving the subscription") | |||
} | |||
|
|||
if _, err = p.API.ShareChannel(&model.SharedChannel{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be conditional on the configuration setting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necesarilly, if you enable the shared channels it would work, if not it shouldn't be a problem. This way we exercise more machinery during this changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I going to put this behind the config flag to be able to reduce surface here while the metrics are off. But that can leave the system in a weird state where only after restart some channels are really shared with Shared Channels (not very important for now).
server/plugin.go
Outdated
PluginID: pluginID, | ||
CreatorID: botID, | ||
AutoShareDMs: true, | ||
AutoInvited: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remind me what this does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't require to go through the Invite process that shared channels require.
server/plugin.go
Outdated
if !p.configuration.MetricsForSharedChannelsInfrastructure { | ||
return nil | ||
} | ||
p.GetMetrics().ObserveMessageSharedChannelsEvent("attachment_created") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering what the point of the "feature flag" here is? Feels like we should be turning it on or off depending on the feature flag, and always measuring metrics. If we can't reliably "turn it off", maybe the feature flag is itself not useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are deciding to execute or not the metrics based on the config setting, but as you said, if there is not messages flowing because the shred channels features is off that maybe is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should consider skipping shared channels for channels, given our focus on DMs and GMs. There are edge cases here like what to do with existing subscriptions that we're not solving for, and I worry that a half-baked approach might be more confusing than adding support for shared channels explicitly later. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The amount of complexity of including shared channels for channels is minimal, I don't see much value on that for this specific case and for now. Let's see how it behaves, and as soon as we see a rock in the road we can disable channels, but for now, I don't feel the need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So to be clear, we can't really disable shared channels with this PR -- we can disable collecting metrics, and we can disable the shared channels subsystem, but all the other side effects (e.g. failure to unshare a channel above) aren't feature flagged and can't be "rolled back" if they go wrong.
I'm advocating for not adding partial code unless we're going to spend the effort to productize it -- as it stands right now, we have no plan to figure out what to do with these older linked channels, and probably won't revisit until after June. It would be great if we could keep the total surface area of complexity as low as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are more or less align on allowing to share channels but disabling that feature optionally, giving us less surface exposure to the early adopters but giving the possibility to some of them to enable channels and start testing it.
Heads up I'm looking into the build failures here, @amyblais, and may try to include a narrower scope of this PR into tomorrow's v1.7.0 build. |
@amyblais, I've patched the build issues, but am running into other things that make me think we should push this to v1.8 instead. |
@jespino & @wiggin77, I made some updates to this pull request to focus the scope, mostly around measuring latency bewteen when we process the sync msg relative to when the post was created. I also updated the unit tests, opting to effect some of my simplifications above to make the job of testing easier. I note that this won't "do" anything in environments where we aren't supporting linked channels, but should still be good fodder for our testing infrastructure. |
One oddity is that I don't seem to be getting calls to |
I just double checked my test plugin that logs all the hooks calls and it is getting called. Perhaps metrics are not hooked up there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
This PR adds the usage of the shared channels API in the plugin and start using the metrics for tracking how many "events" are generated from each side (hooks and shared channels).
This PR doesn't include the subscription to the direct messages based on "any connected user on it", that would be a follow up PR.