new contacts not being queued for lookup since site's base directory path changed

There are some warnings about server load preventing cd_sunlight_cron from running, but not for every cron execution. Even when cd_sunlight_cron does run the queue remains empty and users created since the directory change have no Congress data. cd_civicrm just reported, "Processing queued CD lookups" a few minutes ago, but again nothing in queue and no Congress data for recent users.

So any thoughts on how to investigate this? I've looked at the module's queuing logic and unfortunately I don't know enough about various APIs to figure out why it isn't noticing these records.

I've also flushed sites/default/files/civicrm/templates_c and, again, the Drupal cache.

Finally, I searched both databases for a substring of the old directory path. I found some hits in cd_sunlight's cron table but these appear to be info about old lookups. (?) No hits were found in the CiviCRM database.

I could try manually batching these records to see if that will fly, but I really need it to be automated before I launch (and would so love to do that right away).

New information ...

In order to test something else, I deleted the +4 from my own zip code. And what do you know - I was queued for lookup.

So apparently zip code changes are being noticed, but not newly populated zip codes.

Does this help at all?

Just posting an update on the status of this. I've been unable to continue troubleshooting because of a more serious site problem (related? not sure). I'll report back once that has been resolved.

Update: I had some registry problems. I think they are now resolved.

Because Sunlight is still not putting contacts in the queue for lookup, I've tried uninstalling and reinstalling, but no help. I notice, however, that the Drupal uninstall does not delete all data -- for instance, my CiviCRM custom group / fields for Congressional district still exist and CiviCRM contacts still have their districts stored in those records. The module directory also still exists in sites/all/modules.

Question: how can I get a completely clean uninstall without damaging the database?

[My uninstall order was: disable cd_civicrm and uninstall, then disable cd_sunlight and uninstall].

Also (possibly related): when I have attempted to upgrade to a new beta version, update.php doesn't find anything to update. Is this normal behavior?

Another update .... I've been trying to troubleshoot this module without any Drupal or CiviCRM API experience, so apologies in advance if the following isn't helpful.

Again, the basic problem is that nobody is being enqueued for a Congressional lookup although several contacts' postal codes have changed. This problem has not resolved itself following my CiviCRM 4.0.6 > 4.0.7 upgrade.

I've been zeroing in on the code in cd_civicrm.module. During my cron runs, the function _cd_civicrm_process_queue() in that module is being invoked and at that point things appear to get stuck. I've established that the number 0 is being returned by variable_get(cd_civicrm_geocoding_off). The relevant lines seem to be in the early 900s:

// Do geocoding if necessary.
  if (variable_get('cd_civicrm_geocoding_off', FALSE)) {
    _cd_civicrm_contacts_geocode() ;

I'm not sure whether the FALSE is the problem in this case, but here is a Drupal API reference that also seems to suggest the syntax changed between D6 and D7: http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/variab...

I hope this is helpful in identifying a possible fix.