Link update problems when block caching enabled

Addendum: I've also noticed that the discovered links block is often empty (missing) for logged-in and anonymous users, but it appears as expected for the site admin. Once again, disabling caching fixes this.

The discovered links block is configured to be shown to all users (no roles checked, and all users must view the block, in the block settings page)

Digging into the module source code, I see that the node's discovered links are updated in hook_block... which means that the block caching mechanism might interfere with discovered links updates.

According to the hook_block API docs, it appears the hook_block 'list' needs to return a 'cache' entry in order to override default caching:

This seems to fix it for me:

function relatedlinks_block($op = 'list', $delta = 0) {
  switch ($op) {
    case 'list':
      $blocks = array();

      $link_types = variable_get('relatedlinks_types', _relatedlinks_get_type_defaults());
      $top = TRUE;
      foreach ($link_types as $type => $config) {
        if ($config['enabled'] && ($config['block'] || $top)) {
          $top = FALSE;
          $blocks[$type]['info'] = t('Related links: ') . check_plain($config['name']);
          //
          // Per hook_block API spec, it appears we need to add this to cache per node:
          $blocks[$type]['cache'] = BLOCK_CACHE_PER_NODE;
        }
      }

Or have I missed something here? Please advise.

Changing issue title...

Attaching patch for consideration.

Fixing version, since I'm working against the 6.x-1.0-beta2 branch (that's the last one I installed).

Update: We may need to use BLOCK_NO_CACHE in order to ensure that hook_block() view ops are called on every node load:

          $blocks[$type]['cache'] = BLOCK_NO_CACHE;

Feedback welcome and wanted!

Ugh. It appears that D6 fails to pick up block caching mode changes once a block has been registered in the {blocks} table ( #235673: Changes to block caching mode not caught ), which is the case here - changing the ['cache'] = BLOCK_NO_CACHE (or BLOCK_CACHE_PER_PAGE) will have no effect if you've installed and used the module and relatedlinks blocks previously, and uninstalling the module through Drupal's uninstall feature does not remove existing relatedlinks blocks from the {blocks} table!

mysql> select delta, cache from blocks where module='relatedlinks';
+-------+-------+
| delta | cache |
+-------+-------+
| 2     |     1 |
| 3     |     1 |
+-------+-------+
2 rows in set (0.00 sec)

Note that the 'cache' column is set to 1, which is defined in blocks.module as BLOCK_CACHE_PER_ROLE. We need to manually update the {blocks} table to use -1 (defined in blocks.module as BLOCK_NO_CACHE) or 4 (BLOCK_CACHE_PER_PAGE).

mysql> update blocks set cache=4 where module='relatedlinks';
Query OK, 2 rows affected (1.35 sec)

mysql> select delta, cache from blocks where module='relatedlinks';
+-------+-------+
| delta | cache |
+-------+-------+
| 2     |     4 |
| 3     |     4 |
+-------+-------+
2 rows in set (0.00 sec)

*Sigh...*

Related issue -- here's why uninstalling the module doesn't clean out the {block} table's entries for the module:
#735900: Deleting module's blocks when module is uninstalled