summaryrefslogtreecommitdiffstats
path: root/app/plugin_deadlock_test.go
Commit message (Collapse)AuthorAgeFilesLines
* MM-11575: change plugin nil semantics (#9212)Jesse Hallam2018-08-031-4/+4
| | | | | | | | * change MessageWillBePosted nil return semantics * change FileWillBeUploaded nil return semantics * use LogDebug to verify plugin inputs vs. the confusing Delete(User|Team)
* MM-11431: handle plugin deadlocks (#9167)Jesse Hallam2018-07-271-0/+211
* ensure plugin is always shutdown Once we call `.client.Client()` the plugin has started, and must be shut down. `newSupervisor` sometimes returned with an error (and without a reference to the supervisor), leaving the client running indefinitely. * Clarify the documentation to explain that plugin hooks will not trigger until `OnActivate` returns successfully, and will stop triggering just before `OnDeactivate` is called. * test for plugin deadlock * plugin/environment.go: switch to sync.Map From: https://golang.org/pkg/sync/#Map > If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock. The previous `RWMutex` was not safe given that we effectively acquired read locks recursively (hook -> api -> hook). This worked up until we activated or deactivated plugins, tried to acquire a write lock, and the plugin used the API to effectively trigger another hook. Switching to sync.Map avoids this by divesting the need to lock at all, avoiding the potential for a recursive lock in the first place.