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

Issue working with Sentry celery integration #105

Closed
mumumumu opened this issue Jul 10, 2019 · 6 comments
Closed

Issue working with Sentry celery integration #105

mumumumu opened this issue Jul 10, 2019 · 6 comments

Comments

@mumumumu
Copy link

I'm trying to use celery-once with the Sentry celery integration, but I'm running into an issue with how Sentry patches the task tracer.

The issue I'm seeing is that the key before and after the task is patched are different. I believe this is because of how inspect.getcallargs is working with Sentry's wrapped run method.

Would there be anything wrong with storing the key on the task instance like this:

    def get_key(self, args=None, kwargs=None):
        """
        Generate the key from the name of the task (e.g. 'tasks.example') and
        args/kwargs.
        """
        if not hasattr(self, '_key'):
            restrict_to = self.once.get('keys', None)
            args = args or {}
            kwargs = kwargs or {}
            call_args = getcallargs(
                    getattr(self, '_orig_run', self.run), *args, **kwargs)
            # Remove the task instance from the kwargs. This only happens when the
            # task has the 'bind' attribute set to True. We remove it, as the task
            # has a memory pointer in its repr, that will change between the task
            # caller and the celery worker
            if isinstance(call_args.get('self'), Task):
                del call_args['self']
            self._key = queue_once_key(self.name, call_args, restrict_to)
        return self._key
@mumumumu mumumumu reopened this Jul 10, 2019
@cameronmaske
Copy link
Owner

Hi @mumumumu thanks for reporting.
Is this still an issue, or is it solved by getsentry/sentry-python#421?

@mackthehack
Copy link

I'm currently experiencing this issue as well - even after the monkey patch change in the Sentry SDK.
I'm using celery_once 3.0.0 and sentry_sdk 0.10.2 (which includes the monkey patch changes to the method from the above referenced fix). Turning off the celery integration for sentry in settings removes the error.

[2019-08-12 10:39:02,867: WARNING/ForkPoolWorker-4] RuntimeWarning: Exception raised outside body: KeyError('company_id',): Traceback (most recent call last): File "/envs/lib/python3.6/site-packages/celery/app/trace.py", line 472, in trace_task state, retval, uuid, args, kwargs, None, File "/envs/lib/python3.6/site-packages/celery_once/tasks.py", line 129, in after_return key = self.get_key(args, kwargs) File "/envs/lib/python3.6/site-packages/celery_once/tasks.py", line 118, in get_key key = queue_once_key(self.name, call_args, restrict_to) File "/envs/lib/python3.6/site-packages/celery_once/helpers.py", line 72, in queue_once_key restrict_kwargs = {key: kwargs[key] for key in restrict_to} File "/envs/lib/python3.6/site-packages/celery_once/helpers.py", line 72, in <dictcomp> restrict_kwargs = {key: kwargs[key] for key in restrict_to} KeyError: 'company_id'

cameronmaske added a commit to cameronmaske/sentry-python that referenced this issue Aug 22, 2019

Verified

This commit was signed with the committer’s verified signature. The key has expired.
zalegrala Zach Leslie
…ameronmaske/celery-once/issues/105)

Add tests for celery_once.
Move re-usable pytest fixture for celery into a common conftest.py.
@cameronmaske
Copy link
Owner

@mackthehack Are you on Python 2?
If so the latest version of celery once (3.0.1) and this branch for the sentry sdk getsentry/sentry-python#475 should fix your issue.

@mackthehack
Copy link

I'm using python 3.6.

@cameronmaske
Copy link
Owner

Can you try 3.0.1 and see if that fixes the error? It changes how keys are generated.

@cameronmaske
Copy link
Owner

3.0.1 should resolve this issue. I'll re-open if anyone else experiences this.

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

3 participants