Hub::configure_scope clones the current scope under a read lock, invokes the callback on the clone, then replaces the current scope under a later write lock. Two concurrent calls on the same shared Hub can therefore clone the same initial scope, and the later replacement can discard the earlier mutation.
This is a correctness issue for shared Hub instances: concurrent scope modifications can result in data loss when independent mutations are made to the same shared scope.
Expected behavior: concurrent configure_scope calls on the same Hub should apply mutations atomically with respect to each other, or the API documentation should state that concurrent updates may overwrite each other. One possible fix is to run the scope mutation while holding the write lock, for example through with_current_scope_mut; the implementation should account for the existing constraint that calling scope-related Sentry APIs from inside the callback is unsupported and may panic.
Hub::configure_scopeclones the current scope under a read lock, invokes the callback on the clone, then replaces the current scope under a later write lock. Two concurrent calls on the same sharedHubcan therefore clone the same initial scope, and the later replacement can discard the earlier mutation.This is a correctness issue for shared
Hubinstances: concurrent scope modifications can result in data loss when independent mutations are made to the same shared scope.Expected behavior: concurrent
configure_scopecalls on the sameHubshould apply mutations atomically with respect to each other, or the API documentation should state that concurrent updates may overwrite each other. One possible fix is to run the scope mutation while holding the write lock, for example throughwith_current_scope_mut; the implementation should account for the existing constraint that calling scope-related Sentry APIs from inside the callback is unsupported and may panic.