MRQ fails with pymongo WriteError if job result conains dots in dictionary keys

[DataGreed]

We've recently tried to switch from celery to MRQ and ran into a problem. One of our tasks was returning some debug queryset data in a dictionary with keys that contained dots in them (e.g. "result.debug.qs.parameters.some").

The stacktrace was as follows:

2016-10-04 15:49:08.674762 [ERROR] Traceback (most recent call last):
  File "/main/.env/local/lib/python2.7/site-packages/mrq/worker.py", line 546, in perform_job
    job.perform()
  File "/main/.env/local/lib/python2.7/site-packages/mrq/job.py", line 279, in perform
    self.save_success(result)
  File "/main/.env/local/lib/python2.7/site-packages/mrq/job.py", line 364, in save_success
    self._save_status("success", updates)
  File "/main/.env/local/lib/python2.7/site-packages/mrq/job.py", line 438, in _save_status
    }, {"$set": db_updates}, w=w, j=j, manipulate=False)
  File "/main/.env/local/lib/python2.7/site-packages/newrelic-2.66.0.49/newrelic/api/datastore_trace.py", line 43, in _nr_datastore_trace_wrapper_
    return wrapped(*args, **kwargs)
  File "/main/.env/local/lib/python2.7/site-packages/mrq/monkey.py", line 84, in mrq_monkey_patched
    ret = base_method(self, *args, **kwargs)
  File "/main/.env/local/lib/python2.7/site-packages/pymongo/collection.py", line 2237, in update
    check_keys, multi, manipulate, write_concern)
  File "/main/.env/local/lib/python2.7/site-packages/pymongo/collection.py", line 710, in _update
    _check_write_command_response([(0, result)])
  File "/main/.env/local/lib/python2.7/site-packages/pymongo/helpers.py", line 301, in _check_write_command_response
    raise WriteError(error.get("errmsg"), error.get("code"), error)
WriteError: The dotted field 'parameters.some.available' in 'result.result.debug.qs.parameters.some' is not valid for storage.

I think that storing task result "as is" may not be always the right behavior, I suppose there should be some setting that lets you store task results as their string representation to avoid non-obvios errors like this one :)

[sylvinus]

Hi @DataGreed!

We indeed store results as-is by default, to make them searchable for instance.

If you don't want this behaviour it should be easy to write a subclass to Job that stores its results differently and use it instead by changing this:
https://github.com/pricingassistant/mrq/blob/master/mrq/worker.py#L31

Another easier way would also be to subclass Task and always return serialized results in the run methods.

If you have any suggestion on how to make it easier for users, we'd be happy to discuss them! I understand it may be a common issue for others.

Cheers!

[sylvinus]

Any thoughts @DataGreed ?

[sylvinus]

Add this in common issues / FAQ ? #195