Providing a tag option prevents from joining the mesh

[danielo515]

Hello,

For some reason I though that secena-mesh accepts a tag property on its options, therefore I set one. This worked fine for bases, they got up, discover each other and nothing fancy happens.
However, when I provide a tag property on a non-base node the node is not able to join the mesh.
No errors, no timeouts, no problem at all, is it that it is not visible on the mesh nor I can send messages to it.

Here is a basic stupid example:

'use strict';
const seneca = require ('seneca') ();
seneca.use ('mesh', {
    pin: 'role:api,cmd:*'
    , isbase: false
    , port: 0
    , host: '0.0.0.0'
    , bases: [ '127.0.0.1:39999', '127.0.0.1:39001' ]
    , tag: 'someTag'
}).ready (function ()
{

    console.log ('booted', this.start_time );
    seneca.add ('role:api,cmd:*', (msg, reply) =>
    {

        console.log (msg);
        reply (null, msg);
    });
});

If I comment the tag property, then it works as expected and it joins the mesh.
As I said, this works without problem for bases.

Any explanation ?
Regards

[danielo515]

I think I found the problem.
I just had to read the code of seneca-mesh and sneeze (which is used by seneca-mesh).
According to sneeze documentation it accepts a tag option that behaves just like I suspected:

tag: null
You can have multiple Sneeze networks running at the same time. Each network can have its own tag. Members with different tags will ignore each other.

A tag of null means observe all other members, regardless of tag. This is what you need for base nodes, a repl, or monitoring - see below.

Seneca-mesh takes an undocumented tag property that pass to sneeze, hence the behavior I reported.
I was using the tag property when instantiating seneca and at some point I accidentally added it to the config of seneca-mesh too.

Hope this helps someone. You can close this issue or keep it open as a remind to add such documentation.

Regards