Make 'depends' field a little more tolerant of malformed data #155
Conversation
| from .base import DirtyableList, Field | ||
|
|
||
|
|
||
| class DependsField(Field): |
There was a problem hiding this comment.
Renamed this field since the name was potentially misleading, and given that we long ago made this field specific to the idiosyncrasies of 'depends', it's probably reasonable to name it to indicate that.
| return DirtyableList([]) | ||
|
|
||
| try: | ||
| # In task-2.5, this moved from a comma-separated string to a real list. |
There was a problem hiding this comment.
I can't find any evidence of this and I wonder if this is actually referencing the on-disk format, possibly?
Looking at the docs, the value of this field is indeed a string: https://taskwarrior.org/docs/design/task.html#attr_depends
That all being said -- the weirdness I see on Inthe.AM is that there's a JSON-serialized list stored in this text field 🤷.
Nevermind -- the linked doc there clearly says that in the future this might be converted to return a list.
| return ",".join([str(v) for v in value]) | ||
| else: | ||
| # We never hit this second code branch now. taskwarrior changed | ||
| # API slightly in version 2.5, but we're just going to go with |
There was a problem hiding this comment.
Also don't think this is true, either! See https://taskwarrior.org/docs/design/task.html#attr_depends.
Actually, looking at the field, they do specifically say that "in the future" this will be changed to be a list:
Note that in a future version of this specification, this will be changed to a JSON array of strings, like the "tags" field.
All I can say is that it's clearly not a list in at least 2.5.3 locally for myself.
|
Let's hold off on reviewing this, actually -- I did a little more research as part of https://github.com/coddingtonbear/python-taskwarrior and discovered a couple things:
I'm not clear if the corrupted data will make that not work, though! |
On Inthe.AM, I very regularly encounter malformed values for
depends. I'm not even slightly sure what kind of bug is causing this, but I'm fairly sure it's between a taskwarrior client and the taskserver itself, and thus the fix is a little outside our wheelhouse here. That being said: I recognize that this kind of strategy is controversial, so I welcome discussion about this approach.What this does is, should an incoming value for
dependsnot be deserializable, attempt to extract all findable UUIDs in the field using a regular expression.