search failed: can't get all tasks

[punassuming]

I get this error in emacs log :

Reading [application/xml]... 732 bytes of 723 bytes (101%)
if: Search failed: "^[  ]*:ToodledoID:[     ]*223372634"
byte-code: Beginning of buffer [2 times]
byte-code: Beginning of buffer

When using debug mode, I don't see any errors, it just halts as if everything is ok. Using latest pull from here.

Here is the task info I can see in the debug for 223372634

<task><id>223372634</id><title>Rex</title><modified>1317071308</modified><completed>0</completed><parent>0</parent><folder>6609629</folder><context>1758824</context><goal>0</goal><priority>0</priority><repeat></repeat><repeatfrom>0</repeatfrom><duedate>0</duedate><startdate>0</startdate><duetime>0</duetime><starttime>0</starttime><length>0</length><status>0</status><note></note></task>

It is a parent of 4 tasks. I have about 250 tasks on TD, and this syncs ~80

[christopherjwhite]

Hey Rich,

Any comments on that task with title "Rex"? Before the sync, did you have this task (or any tasks) in the org-mode buffer? Anything interesting about this task compared with other tasks? Had you perhaps deleted it locally and were trying to sync?

Right before the error, do you see any of these messages?

• "Iterating over all tasks in the buffer, looking for changes"
• "Examining task: <....>"
• "...new task..."
• "...deleted task"
• "...edit task..."
• "Successfully synched new task..."
• "Successfully edited task..."
• "Successfully deleted ..."

These might help localize the problem, even if it mentions a different task than the one causing the error.

Last but not least, you can try `toggle-debug-on-error' and try it again. If it stops it will generate a backtrace that might tell me where in org-toodledo-sync it got stuck.

In the meantime, I'll try to improve the error handling.

Thanks ...cj

On Tue, 31 Jan 2012 09:52:06 -0800 Rich Alesi reply@reply.github.com wrote:

I get this error in emacs log :

Reading [application/xml]... 732 bytes of 723 bytes (101%)
if: Search failed:

"^[ ]_:ToodledoID:[ ]_223372634" byte-code: Beginning of buffer [2 times] byte-code: Beginning of buffer

When using debug mode, I don't see any errors, it just halts as if everything is ok. Using latest pull from here.

Here is the task info I can see in the debug for 223372634

22337263413170713080066096291758824000000000

I have about 250 tasks on TD, and this syncs ~80

---

Reply to this email directly or view it on GitHub: https://github.com/christopherjwhite/org-toodledo/issues/8

[punassuming]

I think I found the problem. I had hashes in the text of a few tasks, including some of the children of the aforementioned "REX" task, taking all of them out seems to have fixed the problem.

[christopherjwhite]

Aah -- very interesting. I'll play with that. If you can provide an example of what you think was failing, that would help.

That reminds me that I think there is also an issue if you use "*" as the first character of a line, as that's a key character for org-mode...

Thanks Rich, ...cj

On Wed, 1 Feb 2012 22:51:20 -0800 Rich Alesi reply@reply.github.com wrote:

I think I found the problem. I had hashes in the text of a few tasks, including some of the children of the aforementioned "REX" task, taking all of them out seems to have fixed the problem.

---

Reply to this email directly or view it on GitHub: https://github.com/christopherjwhite/org-toodledo/issues/8#issuecomment-3773519

[punassuming]

OK, it turned out that it as something in one of the children. It only worked when I took the parent task away and just kept the children on the top level. I can not figure for the life of me why they failed, but I will keep it as it is.

Right now, I am working on trying to get syncing work. I have all the tasks load, but at the end, get a setq error. This error allows me to dl I believe all my tasks, but any changes to the org are not synced back. ie, I will delete a task in the org file, and it will be added to the end of the org file again

End of Debug

[10:55:24] Checking for deleted tasks (local-lastdelete-task "0", server-lastdelete-task "1327609086"
[10:55:24] Server has deletes, asking for all after="0"

End of message buffer

Contacting host: api.toodledo.com:80
setq: Args out of range: 1, 2

[christopherjwhite]

Hi Rich,

Comments below...

On Thu, 2 Feb 2012 08:04:35 -0800 Rich Alesi reply@reply.github.com wrote:

OK, it turned out that it as something in one of the children. It only worked when I took the parent task away and just kept the children on the top level. I can not figure for the life of me why they failed, but I will keep it as it is.

The original error that you were getting indicated that org-toodledo tried but failed to find the "REX" task in the buffer. So perhaps the problem is directly with the REX task, and when it got to the children of REX, it tries to link them up in the buffer and so is looking for the REX task and fails.

Is the REX task itself the one with hashes? When you move the child tasks to the top level but keep the REX task, does the REX task make it to the org buffer?

Right now, I am working on trying to get syncing work. I have all the tasks load, but at the end, get a setq error. This error allows me to dl I believe all my tasks, but any changes to the org are not synced back. ie, I will delete a task in the org file, and it will be added to the end of the org file again

End of Debug

[10:55:24] Checking for deleted tasks (local-lastdelete-task "0",

server-lastdelete-task "1327609086" [10:55:24] Server has deletes, asking for all after="0"

End of message buffer

Contacting host: api.toodledo.com:80
setq: Args out of range: 1, 2

This one sounds a bit familiar, I think I've seen this as an error in the lower level http lisp code. If I recall correctly, this occurred when the connection to the server died in the middle and the http layer did not have proper handling.

Can you try `toggle-debug-on-error' and get a backtrace?

Thanks ...cj

[punassuming]

Here is is:

(when (> (string-to-number server-lastdelete-task) (string-to-number local-lastdelete-task)) (org-toodledo-debug "Server has deletes, asking for all after=%S" local-lastdelete-task) (aput (quote params) "after" local-lastdelete-task) (setq server-delete-tasks (org-toodledo-get-deleted params)) (mapc (lambda ... ...) server-delete-tasks)) (let ((local-lastdelete-task ...) (server-lastdelete-task ...) params) (org-toodledo-debug "Checking for deleted tasks (local-lastdelete-task %S, server-lastdelete-task %S" local-lastdelete-task server-lastdelete-task) (when (> ... ...) (org-toodledo-debug "Server has deletes, asking for all after=%S" local-lastdelete-task) (aput ... "after" local-lastdelete-task) (setq server-delete-tasks ...) (mapc ... server-delete-tasks))) (if skip-import nil (org-toodledo-goto-base-entry) (let (... ... params) (org-toodledo-debug "Checking for edited tasks (local-lastedit-task %S, server-lastedit-task %S" local-lastedit-task server-lastedit-task) (when ... ... ... ... ... ...)) (org-toodledo-goto-base-entry) (let (... ... params) (org-toodledo-debug "Checking for deleted tasks (local-lastdelete-task %S, server-lastdelete-task %S" local-lastdelete-task server-lastdelete-task) (when ... ... ... ... ...))) (unless skip-import (org-toodledo-goto-base-entry) (let (... ... params) (org-toodledo-debug "Checking for edited tasks (local-lastedit-task %S, server-lastedit-task %S" local-lastedit-task server-lastedit-task) (when ... ... ... ... ... ...)) (org-toodledo-goto-base-entry) (let (... ... params) (org-toodledo-debug "Checking for deleted tasks (local-lastdelete-task %S, server-lastdelete-task %S" local-lastdelete-task server-lastdelete-task) (when ... ... ... ... ...))) (let* ((regexp ...) (account-info ...) (columns-pos ...) server-edit-tasks server-delete-tasks new-tasks (new-tasks-count 0) new-child-tasks-alist new-parent-new-child-alist edit-child-tasks-alist new-parent-edit-child-alist edit-tasks delete-tasks tasks-by-title-alist (end nil)) (when columns-pos (org-columns-quit)) (unless skip-import (org-toodledo-goto-base-entry) (let ... ... ...) (org-toodledo-goto-base-entry) (let ... ... ...)) (goto-char (point-min)) (org-toodledo-debug "Iterating over all tasks in buffer, looking for changes") (while (re-search-forward regexp end t) (let* ... ... ...)) (while new-tasks (setq new-tasks-count ...) (let ... ... ... ... ...)) (when edit-tasks (let ... ...)) (when delete-tasks (let ... ...)) (unless skip-import (org-toodledo-goto-base-entry) (setq account-info ...) (org-entry-put ... "ToodledoLastSync" ...) (org-entry-put ... "ToodledoLastEdit" ...) (org-entry-put ... "ToodledoLastDelete" ...)) (when columns-pos (goto-char columns-pos) (org-columns)) (let* (... ... ... ... ... ...) (if ... ... ... ...) (list tot imod idel onew omod odel))) (save-excursion (let* (... ... ... server-edit-tasks server-delete-tasks new-tasks ... new-child-tasks-alist new-parent-new-child-alist edit-child-tasks-alist new-parent-edit-child-alist edit-tasks delete-tasks tasks-by-title-alist ...) (when columns-pos ...) (unless skip-import ... ... ... ...) (goto-char ...) (org-toodledo-debug "Iterating over all tasks in buffer, looking for changes") (while ... ...) (while new-tasks ... ...) (when edit-tasks ...) (when delete-tasks ...) (unless skip-import ... ... ... ... ...) (when columns-pos ... ...) (let* ... ... ...))) org-toodledo-sync() call-interactively(org-toodledo-sync nil nil)

[christopherjwhite]

I can't quite tell what the problem is from that backtrace. Does this still occur with the version 2.5? The key fix here is the patch2 file that fixes a problem with the underlying url-http that may be causing some problems.

If it's still happening, any chance you can tell me more about the state of the buffer (what tasks you have) and what tasks are on the server when you sync? The above seems to indicate it's processing deleted tasks when it dies. I've been playing around with variations of deleting tasks on the server and locally and can't reproduce the issue.

Any additional logs you get provide will help, thanks.

[punassuming]

figured out the first problem. My toodledo parent didn't have the same contexts as its children, something I guess that is not allowed in orgmode

[christopherjwhite]

I still can't reproduce the problem. I've been playing with a parent and a child task with different contexts, and having no issues at all.

Can you provide an example? If it's easily reproducible, can you provide the exact text of the tasks that cause the problem, including the context names? I'm wondering if it has something to do with strange characters in the context names.

Thanks ...cj

On Thu, 9 Feb 2012 19:39:23 -0800 Rich Alesi reply@reply.github.com wrote:

figured it out, the first problem. My toodledo parent didn't have the same contexts as its children, something I guess that is not allowed in orgmode

---

Reply to this email directly or view it on GitHub: https://github.com/christopherjwhite/org-toodledo/issues/8#issuecomment-3900692

[christopherjwhite]

Rich,

I just pushed version 2.8 up to git hub. This has significantly better error handling. If an error occurs while syncing a task, it will log the task along with what error code came back from the server for that specific task. It should continue syncing all other tasks without stopping.

Hopefully this will help, either no more issues, or at least a much better idea of where things are failing.

Be sure you have both url-http patches installed if you are running emacs 23, as the second one in particular fixes a problem that may occur frequently.

Let me know how it goes! ...cj

[xuning97]

I met with similar issue, checked the code, that's because the parent task appears after child tasks, so goto-entry cannot find the parent task.

[christopherjwhite]

Aah -- that's a good clue. Let me see if I can reproduce it now. That will take a bit of coding to cache child tasks until the parent is found, but shouldn't be too bad.

[xuning97]

don't have much lisp programming experience, otherwise, I'd like to help solve it..

[christopherjwhite]

Ok, based on the recent comment from xuning97, I was able to reproduce this. Force a child task to get retreived from the server before the parent task is known. Version 2.9 fixes this. Closing with the hope that this is the same problem that was originally seen.