I just tried using straight for org, and master (a1e5bee5c) has a rewritten org-update-id-locations that uses regexps to find the IDs. It appears to have fixed the problem (for cases that I tried).
-Justin On 7/30/20 4:21 PM, Justin Vallon wrote: > I copy by org files between 2 machines. Thus, my .org-id-locations file > gets stale when I archive on one machine, then sync the org files. > > I also use org-edna. > > Sometimes, org-agenda will go into an infinite loop (recursion depth, > etc) when scanning. > > I believe what is happening is: > > - org-agenda / org-edna builds the agenda, and hits a "missing" id(X) > - org-update-id-locations starts scanning files/nodes to refresh > - org-cached-entry-get tries to get all properties > - org-entry-blocked-p is called > - org-edna then tries to parse the BLOCKER property > - the property mentions "id(Y)", which has not been found (yet) > - cache miss, rescan files > > The X and Y could be different, but once id(Y) is missing and the > cache-miss happens during id-scanning, it will repeat. > > I suppose it also might be sensitive to the order of files in the list, > since scanning the archive first would scan the older IDs, then the > active file would reference those older IDs. However, I would imagine > there would be trouble if an "earlier" node in the active file > referenced an ID that appeared "later" in the file, since the file is > being scanned in-order. > > I haven't tried this, but the simplest case to reproduce might be to > delete the .org-id-locations file, then feed it: > > * Second > BLOCKER: id(first) > * First > ID: first > > I can try to build a (simple) reproducible test case if this is unclear. > > My work-around is to disable org-edna, run org-id-update-id-locations, > then reenable org-edna. > -- -Justin justinval...@gmail.com