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

Initial usage of share channels api (Only triggering metrics) #467

Merged
merged 38 commits into from
Feb 14, 2024

Conversation

jespino
Copy link
Member

@jespino jespino commented Jan 4, 2024

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.

@jespino jespino changed the title Initial usage of share channels api Initial usage of share channels api (Only triggering metrics) Jan 23, 2024
server/plugin.go Outdated
@@ -426,6 +428,36 @@ func (p *Plugin) OnActivate() error {
}
}

remoteID, err := p.API.RegisterPluginForSharedChannels(model.RegisterPluginOpts{
Copy link
Member Author

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?

Copy link
Member

@wiggin77 wiggin77 Jan 24, 2024

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

@jespino jespino marked this pull request as ready for review January 23, 2024 16:58
@codecov-commenter
Copy link

codecov-commenter commented Jan 23, 2024

Codecov Report

Attention: 94 lines in your changes are missing coverage. Please review.

Comparison is base (4e3aa66) 41.55% compared to head (47cd17e) 41.07%.

Files Patch % Lines
server/plugin.go 0.00% 86 Missing ⚠️
server/command.go 71.42% 2 Missing and 4 partials ⚠️
server/api_nomock.go 0.00% 1 Missing ⚠️
server/message_hooks.go 83.33% 0 Missing and 1 partial ⚠️
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.
📢 Have feedback on the report? Share it here.

server/plugin.go Outdated Show resolved Hide resolved
server/plugin.go Outdated Show resolved Hide resolved
plugin.json Outdated Show resolved Hide resolved
plugin.json Outdated Show resolved Hide resolved
Copy link
Member

@wiggin77 wiggin77 left a 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.

@lieut-data lieut-data added this to the v1.7.0 milestone Jan 24, 2024
Copy link
Member

@lieut-data lieut-data left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @jespino! A few thoughts as we figure out how to roll this out and start measuring impact.

@wiggin77, could you also refresh me as to what metrics shared channels itself already exposes and how we might want to start monitoring that from a Grafana dashboard?

go.mod Outdated Show resolved Hide resolved
plugin.json Show resolved Hide resolved
plugin.json Outdated Show resolved Hide resolved
@@ -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{
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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/command.go Outdated Show resolved Hide resolved
server/plugin.go Outdated Show resolved Hide resolved
server/plugin.go Outdated
PluginID: pluginID,
CreatorID: botID,
AutoShareDMs: true,
AutoInvited: true,
Copy link
Member

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?

Copy link
Member Author

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 Show resolved Hide resolved
server/plugin.go Outdated
Comment on lines 802 to 805
if !p.configuration.MetricsForSharedChannelsInfrastructure {
return nil
}
p.GetMetrics().ObserveMessageSharedChannelsEvent("attachment_created")
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

@lieut-data
Copy link
Member

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.

@lieut-data lieut-data modified the milestones: v1.7.0, v1.8.0 Feb 7, 2024
@lieut-data
Copy link
Member

@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.

@lieut-data
Copy link
Member

@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.

@lieut-data
Copy link
Member

One oddity is that I don't seem to be getting calls to OnSharedChannelsAttachmentSyncMsg -- or at least the metrics aren't capturing anything. I haven't debugged yet, but wondering if you have any suggestions @wiggin77?

CleanShot 2024-02-09 at 23 06 26@2x

@wiggin77
Copy link
Member

I don't seem to be getting calls to OnSharedChannelsAttachmentSyncMsg

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.

Copy link
Member

@wiggin77 wiggin77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@wiggin77 wiggin77 merged commit 0c4f8d2 into main Feb 14, 2024
7 checks passed
@wiggin77 wiggin77 deleted the shared-channels-plugin-api branch February 14, 2024 20:47
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

Successfully merging this pull request may close these issues.

4 participants