How does info:entry work?

[kevin-madhu]

I replicated similar code, and tried to send info messages like
this.act('info:entry',entry.data$())
in the post service. But, the services kept on dying with act_not_found error.
So, I tried to find out if the same thing happens in this code base - cloned the project, removed all the services except base, api, entry-store and post and found that the services don't die even though none of the services implement 'info:entry' pattern. Then I came across

var OPTS = (process.env.OPTS || '--seneca.options.debug.undead=true --seneca.options.plugin.mesh.sneeze.silent=1')

in the fuge-config.js and removed it completely, but services were still fine with the message.
I tried matching all the seneca configuration and ended up with very identical code in both my replica and ramanujan, but still my replica failed, while ramanujan was fine with unimplemented messages. Finally, I gave up trying matching code and packages and used

seneca.act({exhausted: true, message: 'not_implemented', default$: {}})
as suggested by senecajs/seneca#219, but it's ugly :)

But I'm still curious about how ramanujan keeps his cool about unimplemented messages. Also please suggest if I should choose to make info messages look like all the other messages in the services like in this project(dunno how!) or go with adding default$:{} for each one of them(a little bit explanation can help).

Thanks 🍻

[rjrodger]

There should be a default action defined for info:entry to handle this case.

The main system is depending on other services that listen for info:entry being live and registered on the mesh, thus registered an info:entry pattern